网页教程

实体SEO的出发点是一个大多数优化建议至今仍然忽略的事实：搜索引擎早就不再匹配字符串了。它们匹配的是事物。一个页面得到什么分数，并不取决于它是否包含某个词组，而取决于系统是否相信这个页面讲的是词组背后的那个概念，以及系统对这个概念到底是什么有多大把握。 这个区别决定了重复关键词究竟对你有帮助，还是完全不起作用。在匹配字符串的系统里，重复是一种信号。在匹配实体的系统里，重复只是噪声，真正能推动结果的，是机器能不能识别出你是什么。 判断你是否作为实体存在的测试： 搜索你的公司名称，看看在没有人追问的情况下，搜索引擎主动给出了关于你的哪些信息。如果它只返回首页，别的什么都没有，那么你只是一串它能找到的字符。如果它返回了描述、所在地、类别以...

有排名却从不被引用，是把搜索引擎优化做对了、却眼看着它什么都没带来的那种非常具体的挫败感。排名来了。展示次数在涨。点击却没有跟上，而且把标题标签改写多少遍都不会有变化。 这不是你优化上的失败。这是当结果页不再是一份链接清单、而变成一个答案时必然发生的事。而且它现在已是常态，不是一个值得拿去诊断的异常。 我们自己的数据，来自 Search Console，统计口径是截至 2026 年 8 月初的 28 天： 本站有 531 个查询词排在前十位，带来 28,847 次展示，却只换到 161 次点击。这就是 0.56% 的点击率，而第四到第十位在历史上通常能拿到 2% 到 8%。这 531 个查询词里，有 452 个一次点击都没有产生。 ...

llms.txt 现在到底有没有用？诚实的答案是：在可测量的范围内几乎没有用，而那些告诉你这个文件对 AI 可见性至关重要的人，通常是在向你推销东西。一边这样说，一边又建议你发布一份，这个立场并不舒服。所以这篇文章先把数字摆出来，然后再解释这条建议本身。 文件本身是个合理的主意。它是放在网站根目录下的一份 markdown 索引，告诉语言模型你发布了什么、内容在哪里，就像 robots.txt 告诉爬虫哪些内容可以抓取一样。想法没有问题。问题出在它原本要服务的那些公司身上，它们几乎没有采用。提出一份规范，和真正出现读取它的一方，完全是两回事。 服务器日志真正显示的情况： Ahrefs 对 137,000 个域名的分析发现，2026 ...

要不要屏蔽 AI 爬虫，通常被摆成一个技术问题，但它并不是。屏蔽本身只是几行配置，在 robots.txt 里加几条规则，或者在网络层打开一条规则，十分钟就能做完。真正难的是决定你到底想不想这么做，而这个决定完全属于生意范畴：你是在两件事之间做取舍，一边是保护内容不被拿去训练模型，另一边是继续出现在人们如今用来替代搜索结果列表的那些答案里。 网上大部分建议都是先站队，然后只替自己那一边说话。诚实的说法是另一种：正确答案随商业模式而变。一家靠页面浏览量吃饭的媒体，和一家靠询盘吃饭的服务公司，本来就应该得出完全相反的结论。如果两者的答案一样，那才是真的出了问题。 这笔交易一句话就能说完： 屏蔽 AI 爬虫可以阻止你的内容被抓取消化，但同...

Cloudflare Queues 解决的是每个无服务器应用迟早都会撞上的那个问题：一个请求到达，触发了一段用户本不该等待的工作。发送确认邮件、给上传的图片改尺寸、把记录同步到第三方服务。这些活儿的共同点是：它们必须发生，但并不需要在用户按下按钮的那一刻发生。在传统服务器上，你把这类活儿交给一个后台工作进程就行了。可是在 Workers 上，请求处理完就结束，根本没有可以交出去的常驻进程。 常见的几种绕开办法，比看上去更糟。把工作放在请求里同步做完，等于让用户去等一个邮件服务商的响应。向另一个 Worker 发出请求却不等待它，只要发起方的调用先结束，这个任务就丢了。这两种做法都扛不住服务商的一次故障。 队列真正给你的是什么： 是持...

Cloudflare Hyperdrive 的存在，是为了解决一个非常具体、也毫不光鲜的问题：一个在 200 座城市里运行的 Worker，去和一座城市里的那一个 Postgres 数据库对话，会比同一条查询从紧挨着这台数据库的服务器发出更慢。不是慢一点点，而往往是慢上好几倍，而且这些原因和查询本身怎么写完全没有关系。 当一个无服务器应用显得迟钝时，人们的第一反应通常是怪查询规划器，或者再加一个索引。但在与某个区域数据库通信的 Workers 上，查询本身通常没有毛病。真正出问题的是连接。 Hyperdrive 真正修好的东西： 建立一次数据库连接的代价，而且这笔代价要在每一个请求上重新付一遍。一条 Postgres 连接在第一行数...

电商的 GEO 比内容型 GEO 范围更窄，而且在一个具体的地方反而更简单：一个要回答商品问题的助手，想要的是可以直接说出口、不必绕圈子的事实。价格、是否有货、尺寸、兼容清单、退货期限。这些要么以机器可读的形式存在于你的站点上，要么就不存在，而不存在的东西没法被引用。 所以这与其说是写作问题，不如说是数据问题。大部分工作落在商品 feed 和标记上，而不是落在销售文案上，这跟这个领域里其他所有议题的重心正好相反。 决定能否被采用的，是准确度而不是完整度。 一个系统说出了你的价格却说错了，它就产生了一个糟糕的答案，而避免糟糕答案最省钱的办法，就是不再使用不可靠的来源。过期的库存与价格数据是被剔除最快的一条路，而且和排名处罚不同，没有人...

没有人能用当年衡量搜索引擎优化的那套办法来衡量 GEO，原因不是工具不够用，而是结构本身变了。旧指标全都建立在一个前提上：会有人点击。当年值得知道排名，是因为排名可以预测流量，而流量可以预测收入。可是当答案不需要一次访问就被直接送到用户面前时，这条链条在第一环就断了，而它下游的每一个数字仍然照常上报，好像什么都没有发生。 危险的地方正在这里。排名看着正常。会话数看着还撑得住。仪表盘是绿色的，可你真正在意的那一块正在归零，而标准报表里没有任何一栏是为了把这件事告诉你而设计的。 要盯的信号是展示量在涨而点击量持平，而且必须按查询词逐条去看，不能只看整站汇总。 在汇总数字里它是隐形的，因为几个正常增长的页面就足以把它盖过去。在本站，...

多门店 SEO 在几乎每一家尝试的企业身上都以同一种方式跑偏。有人写了一个不错的服务页，按门店数量复制一遍，把城市名换掉，然后发布十二个百分之九十五雷同的页面。感觉像是把规模做起来了。它的行为却是重复，而且往往把每个点位都压住，而不是帮上任何一个。 这种本能可以理解，因为围绕同一项服务写出十二个真正不同的页面，既难又贵。可这条捷径产出的，是搜索引擎没有理由在其中偏爱任何一个的页面，于是它挑一个，排名还不稳定，其余的一概不理。 能解决大半问题的那条规则： 一个门店页必须包含只对这家门店成立的东西。不是把城市名塞进一段通用文案，而是真实的人员、真实的停车、真实的营业时间、真正覆盖的区域，以及真的在附近做过的活。如果换成另一家门店，页面上...

白牌网站开发，是设计或营销代理把一个建站项目卖给自己的客户，再由一家独立的技术伙伴以代理的名义、隐身完成交付的安排。它之所以存在，是因为一家小代理的账和一支常设工程团队的账对不上。客户的活是一阵一阵来的，开发者的工资却是每个月都要发，这两件事之间的缺口，正是那些赶在需求之前招人的代理被拖垮的原因。 这个模式做得好会很好，砸起来也很难看，而你拿到哪一种，取决于合作约定的程度远大于代码本身的质量。 你真正在做的那笔交换： 你让出毛利，换来在不背工资的前提下说"接"的能力。对一家以设计为主的代理，这通常是笔划算的交换，因为另一条路要么是推掉活，要么是对着还没签下的机会先招人。它变成一笔坏交换的时刻，是当开发成为你卖的主要东西，因为那时你外...