第一处硬伤：博客列表页首屏没有真实文章链接
在金边做软件这12年，我们团队28个人，客户分布在柬埔寨、菲律宾、越南、老挝、泰国、印尼、马来西亚七个市场。每年交付约100个项目，电商和娱乐类系统有成品，开箱即用，小项目几天就能上线，大项目大约两个月。但在官网项目里反复出现的一个问题和“快”恰恰相反：很多技术团队把博客列表做成客户端异步加载——服务端返回页面骨架，浏览器执行JS后再fetch文章数据渲染卡片。用户侧体验没差别，但Googlebot抓到的HTML里只有一个空容器div，没有任何标签指向文章详情。
GSC里的典型表现是：博客栏目收录正常，但文章详情页收录率极低，或者收录延迟数周。因为Google根本不知道这些文章存在。我们在排查电商类客户的官网时，这个问题出现频率最高，尤其是前端用重型框架、后端只出API的站点。这类客户的成品系统交付很快，但官网的SEO底子往往就是这种架构。菲律宾和越南的客户在这点上尤其明显，他们的开发团队习惯前后端完全分离，官网也是同一套技术栈。
修复方式不复杂。服务端渲染博客列表页时直接查询前12篇文章，把标题、摘要、URL完整输出到首屏HTML。如果前端必须保留客户端交互，可以把首屏数据作为initialArticles参数注入组件，后续滚动加载再走API。关键是：第一次响应里就必须有真实链接，而不是骨架屏。判断标准很简单，查看网页源代码，能看到完整的标签才算过。
第二处硬伤：sitemap里的lastModified在撒谎
不少网站为了省事，所有页面的lastModified都填new Date()——每次请求sitemap都显示“刚刚更新”。这个操作看似无害，实际上在消耗Google对sitemap的信任。我们在做金融/交易类和地产类客户的系统交付时，这类客户的官网经常由内部团队维护，sitemap由开发框架默认生成，时间戳全是当前请求时间。金边本地好几家地产公司的官网就是这么干的，sitemap里几百个URL全部显示同一秒的时间戳。
Google的爬虫调度会参考sitemap中的时间戳决定抓取优先级。如果所有URL永远显示“刚刚更新”，时间信号就失去了参考价值。更糟的是，当Google反复抓取后发现内容根本没变，它对整个sitemap的抓取频率会明显降下来。后续真正重要的更新反而可能被延迟抓取，这个延迟在GSC里能看到具体表现：新页面提交后，等待抓取的时间从几天拉长到几周。
正确做法是用两类真实时间：静态页面用部署时间戳（构建时写入），动态内容用数据库里的updated_at字段。一个页面三个月没动过，就写三个月前的日期。真实比“新鲜”更重要。我们给客户交付系统时，会在sitemap生成逻辑里直接绑定数据库字段，部署时自动写入，不依赖人工维护。
第三处硬伤：产品落地页只有孤零零一个
软件开发公司官网最常见的结构问题是：所有服务挤在一个“产品介绍”页面里，或者只给某个主打产品建了独立页面。比如只做一个/sports-betting，其他业务全在导航栏里用锚点链接凑合。我们在柬埔寨本地接触的不少团队，官网就三四个页面，产品介绍页里从代理系统到支付对接、从白标平台到定制开发全塞在一起，像把公司简介压缩进了一张名片。
这意味着放弃了大量长尾关键词的排名机会。在柬埔寨、菲律宾、越南这些市场做软件交付的团队，客户搜索词可能是“white label betting platform”“agent management system”“payment gateway integration service”等完全不同的意图。一个页面不可能同时命中这些需求。我们自己的电商类成品系统有几十家客户在运营使用，但给客户做官网规划时也不会把所有东西堆在一个页面上。娱乐类客户的搜索意图和电商类完全不同，一个页面塞进去等于自己跟自己打架。
建议至少为以下五类业务分别建立独立落地页：代理系统、支付对接服务、管理后台、白标平台、定制开发。每个页面围绕一个核心关键词展开，讲清楚解决的问题、交付周期、技术栈和部署方式。页面之间用清晰的内部链接串联，形成关键词矩阵。落地页数量对应的是你实际能承接的业务线数量——每一条独立的业务线都值得一个独立的页面。如果你只做电商系统，那三个页面可能就够；如果同时做娱乐、金融/交易、地产、物流，五六个页面是底线。
第四处硬伤：后台入口没有被明确排除
一个容易被忽略但GSC里经常暴露信号的问题是：后台管理入口被Google抓取并尝试索引。/admin和/admin/可能被当作两个不同URL处理，robots.txt只写了其中一个路径，另一个就漏进了索引库。我们在交付物流类和地产类系统时，客户方运维经常只配置了不带斜杠的路径，带斜杠的变体就裸奔在索引库里。泰国和印尼的客户在这类基础配置上出问题的比例不低，可能是运维交接时文档没写清楚。
这类页面出现在搜索结果里没有任何价值，反而稀释了网站整体质量评分。更实际的影响是，后台登录页被收录后，如果页面标题写的是“Admin Login”或者“管理后台”，用户搜索品牌词时可能看到两个结果，其中一个点进去是后台入口——既不转化，也不体面。我们在GSC的“页面”报告里帮客户筛过，有的站后台入口的展示量比产品页还高，点击率极低，纯属浪费抓取配额。
修复分两步：robots.txt里同时覆盖带斜杠和不带斜杠的路径；后台页面的HTML head里统一输出noindex, nofollow的meta标签。双重保险才能确保Google不再浪费抓取配额在这些URL上。检查方法是在GSC的“页面”报告里筛选包含/admin的URL，看还有多少处于已索引状态。
第五处硬伤：结构化数据缺了最关键的成交类标记
多数官网会配置基础的Organization、Article、BreadcrumbList结构化数据，这些属于“身份识别”层面。但真正驱动搜索富媒体展示的是Offer、FAQ、Product这类成交相关标记。我们在给娱乐类和电商类客户做官网优化时，发现后台CMS自带的SEO插件默认只输出基础标记，成交类标记一个都没有。金边这边很多用WordPress的客户，装个Yoast就完事了，插件默认模板里根本没有FAQ和Offer的配置项。
举例：如果产品落地页配置了FAQ标记，用户可以在搜索结果里直接看到“开发周期多久”“是否提供成品系统”“付款方式怎么走”等问题的答案预览。这比单纯两行文字描述占据更大的视觉面积，搜索结果里的视觉占比直接决定点击率。对我们这类提供成品系统的团队来说，FAQ里可以写清楚“电商类系统有成品，开箱即用，小项目几天交付，大项目约两个月”，这些信息出现在搜索结果里本身就构成转化钩子。娱乐类和电商类客户的搜索意图通常带有明确的交易倾向，成交类标记的匹配度比基础标记高得多。
补全结构化数据不需要重构页面，用JSON-LD格式在对应页面head中注入即可。关键是标记内容与页面可见文字一致，不要为了堆标记而写页面里不存在的信息。Google对结构化数据的态度一直很明确：标记和页面内容不匹配，要么忽略标记，要么触发手动处置。我们给客户补标记时，会先让客户确认页面上的FAQ内容是否真实反映交付能力，再写入JSON-LD。
一张可以照着执行的核查表
把上面五处硬伤压缩成可检查的清单，建议每季度跑一遍：
- 博客列表页首屏HTML中是否包含文章详情链接（查看源代码，不依赖浏览器渲染），数量与列表页实际展示的文章数一致
- sitemap中每个URL的lastModified是否来自真实部署时间或数据库字段，抽查至少20个URL确认时间戳不是同一秒
- 产品/服务落地页数量是否与实际业务线数量匹配，每条独立业务线至少一个独立页面
- 所有后台管理路径（含带斜杠变体）是否同时被robots.txt和noindex覆盖，在GSC页面报告中验证
- 结构化数据是否包含FAQ、Offer或Product中至少两类成交标记，且标记内容与页面可见文字一致
完成这五项修复后，GSC里的变化通常从收录数据开始显现：有效页面数上升，展示量逐步爬坡，部分长尾词开始进入前20。具体见效时间因站而异，取决于站点历史、抓取配额和竞争环境。我们在金边给客户做这类优化时，沟通和后续维护走Telegram，系统bug修复不另外收费，新增功能按工作量评估。报价走面谈或Telegram详谈，按功能清单评估，先付30%，验收后结清尾款。支付通道由客户提供资源，我们负责对接。SEO没有魔法，把每一处实现细节做对，数据自然会给出反馈。