外贸网站技术 SEO 从哪里查起？先拿一组真实页面走完检查
审计工具列出几百个问题时，先不要按红色警告的数量分配开发任务。对一个已经上线的外贸网站，更可靠的起点是一组有业务意义的真实页面：看它们怎样被访问、怎样控制索引、能从哪里找到，以及客户能否正常使用。如果首页都打不开，先恢复访问；如果只是部分产品难被发现，就沿那一类页面检查。这篇文章带你完成首轮排查，并明确一次修复怎样才算验收。
先选能代表业务的页面，而不是只测首页
首页通常获得较多关注：图片压过、缓存开了、按钮有人测试。产品模板却可能是另一套代码；博客、分类与询盘页也各有自己的组件。同一个模板生成的页面又可能共享缺陷，因此选样时要同时考虑页面角色和模板差异。
可以选首页、一个产品分类、分类第二页、一个主推产品和一篇文章；如果某种模板最近改过，再选它的一页。数量随网站结构而定，每个样本为什么被选中，都要说得清楚。这组样本用于发现模板问题，不能据此估算全站错误比例。
给每页写一个预期，再去运行工具。下面用一个假设目录说明：/products/ 是产品分类，/products/?page=2 列出另一组产品，/products/model-a/ 是准备获客的型号页，/internal/proposal/ 是仅供授权客户查看的方案。前三个需要公开访问；最后一个需要权限保护。它们出现在“不收录”报表里，意义显然不同。
先把用途、是否应公开、首选地址记在同一份记录中，再填实际状态。否则，很容易把所有“不收录”都当成故障，甚至为了让报表变绿而开放本来不该公开的资料。
沿同一地址确认访问和返回内容
从目标URL直接打开页面，留意地址栏是否发生跳转，然后在浏览器开发者工具的网络面板查看文档请求。页面显示出来，不代表请求过程没有异常：地址可能先跳到旧域名，再转到首页；一个不存在的产品也可能被主题包装成看似正常的页面。把最初地址、最终地址、HTTP状态和实际内容放在一起看，才知道请求到达了哪里。
希望公开展示的正常内容页通常应返回200，并提供该页自己的内容。已经迁移的地址可以有合理跳转，真正消失且没有对应替代内容的页面也不必硬改成200。Google对HTTP状态的说明区分了成功、跳转与各类错误响应；状态码应说明资源实际发生的事，不应成为掩盖缺页的装饰。
如果一次请求超时，先重复检查，并换网络或从服务器侧查看日志。单次失败可能来自本地网络，不能立即判定整站宕机；但同一模板的多个重要页面持续出现服务器错误，就应优先处理。记录异常发生的时间、完整URL和可重复步骤，开发才有机会把它与日志对应，而不是收到一句“Google进不来”。
拿到200后，还要确认响应的确是预期页面。查看源码和渲染后的页面，检查主标题、关键产品说明、图片与主要导航是否出现；使用JavaScript加载内容的网站，更要核对Google实际能看到的版本。Search Console的URL检查提供索引记录和实时测试两种视图。前者反映Google系统已有的数据，后者检查当前页面；改好代码后，旧索引记录没有立即改变，并不一定意味着修改失败。
完成这一步，只能确认“预期地址能稳定返回预期内容”。如果最终地址都不对，压缩图片没有解决当前阻断；地址正确后，再检查页面自己发出的索引控制信号。
把索引控制的三件事分开核对
robots.txt、noindex和canonical经常一起出现在检查工具里，却分别回答不同的问题。robots.txt管理爬虫能请求哪些地址；noindex告诉支持它的搜索引擎不要把相应内容放进索引；canonical表达一组相同或相似页面中，你希望采用哪个版本。把三者当成“收录开关”，就容易得到相互冲突的配置。
比如公开产品页误带noindex，应先确认这是模板设置错误，还是业务人员有意隐藏。确定需要收录后，再移除相关meta标签或HTTP响应头中的限制，并检查同模板页面。不能只看页面源码，因为noindex也可能通过X-Robots-Tag响应头设置。按Google的noindex规则，爬虫还需要能够访问资源，才读得到这一指令；同时用robots阻止请求，可能让它看不到新加的noindex。
这不意味着应该开放私密方案。对不该公开的文件，先保证访问权限，不能仅靠robots或noindex保密。假设目录把方案页单独列出，就是为了避免“修复不收录”越过业务边界。
接着查看canonical的目标是否合理。型号A与型号B有不同参数、应用和采购需求时，不应为了减少重复警告就全部指向分类页。完全相同的参数跟踪版本，可以另行讨论统一首选地址。Google建议保持canonical、站内链接和Sitemap等信号一致，但canonical不是强制命令，最后选择的版本仍需在索引记录中确认。
验收时把“修改已生效”和“Google已采用新版本”分开。前者可以检查当前响应头、HTML与目标URL；后者依赖Google之后的抓取与索引处理。不要因为实时测试通过，就在交付记录里写“收录问题已经全部恢复”，也不要在没有重新检查前反复切换canonical，制造更多无法解释的变化。
顺着分类和分页找到产品
访问和索引控制没有明显问题，再检查页面能不能被发现。回到分类页，不使用站内搜索，沿正常导航找到那个主推型号。如果你知道产品URL才能访问它，分类、相关推荐和文章中都没有入口，这就是需要解释的断点。重要页面应有清楚的进入路径，但没有“一页超过150个链接，后面的链接就失效”的可靠通用阈值。
查看链接是否有真实目标地址。Google建议使用带href的a元素，而不是只有点击事件、没有可解析URL的伪链接。按钮在你的浏览器里能触发动作，不等于爬虫可以沿它发现下一页。链接由JavaScript生成也不必直接判错，重点是生成后的HTML是否提供了可以访问的目标。
假设目录的第二页列出不同产品，就不能仅因为它与第一页共用模板，便把canonical统一指向第一页。Google的分页实践建议各页有自己的URL与canonical，并通过正常链接串联。它不再用rel next/prev来识别分页关系，但这不要求你删除对其他系统仍有用的标记；更值得优先检查的是下一页能否真正被访问。
Sitemap是另一条发现路径，不能代替站内导航。放入你希望搜索展示的首选绝对地址，检查有没有误收跳转页、失效页面或不该公开的资料。单个Sitemap的限制是50,000个URL或50MB未压缩大小，超出再拆分；小网站不需要为了显得专业，把每种页面拆成很多空文件。
分类第二页是否正常，关系到产品的连续发现路径；型号页的独立说明与首选版本，又关系到它是否被正确区分。若这些条件已满足仍未收录，应继续评估内容价值、重复情况及Google处理状态，不要盲目增加技术设置。
看访问者遇到的卡顿，不只看分数
再观察客户是否用得顺畅：首屏内容是否迟迟不出现，菜单点击后是否没有反应，图片是否把询盘按钮挤走。完全点不了的表单有直接业务影响，不必等索引结果出来才修。
当前Core Web Vitals使用LCP、INP和CLS，分别衡量加载、响应和视觉稳定性，不再用FID代表当前组合。Chrome团队给出的良好体验阈值是LCP不超过2.5秒、INP不超过200毫秒、CLS不超过0.1，并按移动与桌面的第75百分位评估。一次本地跑分不是这组真实用户结果。
性能工具的价值是帮助你定位原因。若首屏大图迟迟出现，检查文件大小、响应式尺寸和加载顺序；若点击菜单时卡顿，检查相关脚本任务与事件处理；若页面跳动，检查图片、嵌入组件和字体的空间变化。把这些动作与实际异常对应，比“所有脚本统一延迟三秒”可靠。后者可能让菜单和表单一起失效，甚至破坏统计。
图片显示宽度也不能单独决定应该传多大文件。手机的设备像素比、屏幕尺寸和设计清晰度需求会影响选择，响应式图片可以让浏览器挑选合适版本。处理之后既要比较下载量和性能记录，也要查看图片是否模糊、裁切是否挡住信息。文件越小越好，并不是完整验收标准。
移动端需要实际操作，而不是只把桌面窗口缩窄。检查菜单、横向表格、弹窗关闭和询盘输入。旧教程中的Search Console移动设备易用性报告已经退休，不要再让团队寻找这个入口；这不表示移动体验不重要。可以用现有浏览器调试和性能工具辅助检查，再在真实设备上验证关键流程。
把修复完成拆成三个可以核对的时点
开始改动前，保存相关配置和样本的检查结果，并写明如何恢复。若改的是产品模板，验收时除了最初出错的型号，也要检查同模板的另一个产品与没有修改的对照页面。一个样本变好、另一个型号丢了内容，不应算作完成；一张首页高分截图也不能替代这一轮回归。
改完立即能核对的是当前事实：状态码、最终地址、索引指令、canonical、链接、图片、菜单和表单是否符合预期。之后才是Google的处理结果：它是否重新抓取，索引记录是否变化，选择的canonical是否符合预期。再往后，真实用户性能与搜索表现需要积累相应样本，不能在改完当天凭一次测试提前下结论。
这三类时间不是固定等待几天的日程表，而是三种证据什么时候才可能成立。服务器当前返回正确内容可以立即确认；Google没有重访时，旧记录仍可能保留；真实用户样本不足时，应该记录数据缺失，而不是把空白当成零错误或良好体验。若要进一步区分技术条件和排名机制，可以阅读谷歌算法与页面评分的边界。
检查结束时，留下一个可以交给下一位同事复验的结果：哪个URL出现了什么问题，影响哪类模板，改了哪里，当前验证了什么，哪一部分仍待Google处理或真实用户数据确认。这样安排技术SEO协作时，讨论的是工作范围与验收，不是工具里还剩几个红灯。
技术SEO栏目提供各环节的延伸阅读，SEO完成标准区分修复与长期结果。先把一个主推产品和所属分类的下一页检查清楚：预期内容、进入路径及改前改后记录都对得上，再扩展到其他模板。
