技术SEO审计应该检查哪些问题？从URL抽样到可执行的修复清单

这类审计面向网站和页面模板。单篇文章的Title、描述与H标签如何填写，可以直接使用页面SEO检查清单；这里重点处理检查范围、抽样、技术信号和修复交接，避免只拿工具的总分判断整站。

第一次检查，先拿一个重要页面走完这六步

先选一张希望从搜索获得访客的页面，例如服务页或核心教程。退出管理员登录，用普通窗口打开它，再依次记录下面六项。先完成一个样本，才能看懂批量报告里相同字段的含义。

先查什么	到哪里看	留下什么结果
请求和最终地址	浏览器Network中的主文档	HTTP状态、是否跳转、最终URL
索引指令	响应头与HTML	是否出现意外的noindex
规范网址	HTML的rel="canonical"	实际目标，以及是否符合页面用途
主要内容	公开页面和可用测试HTML	标题、正文、重要链接是否完整
站内入口	导航、分类、相关旧文	能从哪张公开页面点进来
手机功能	手机或移动视口	菜单、表格、表单和按钮能否使用

有一项失败，先记录原样证据；全部正常，再把同类页面放进批量检查。六步是入门顺序，后面仍要比较URL清单、抽查不同模板、处理性能及适用的扩展。不要用一个正常样本代表全站。

审计工具分别能回答什么

先给工具分工，能减少把同一个数字反复核对却没有结论的情况。浏览器适合复现用户实际看到的内容；爬虫适合批量寻找响应、链接和模板信号；Search Console说明Google报告过的状态；服务器日志则记录请求到达服务器时发生了什么。这几种证据互补，不能互相替代。

证据来源	主要用途	解读时先确认
浏览器与开发者工具	看公开页面、网络请求、响应头与渲染内容	是否未登录、设备和缓存条件是否一致
网站爬虫	批量收集URL、链接、状态、规范与索引标签	起点、包含范围、渲染方式、访问身份和限制
Search Console	查看Google已知索引、抓取和效果信息	报告日期、资源范围、历史结果与实时测试的区别
服务器或CDN日志	核对请求路径、时间与响应	日志覆盖层、保留时间及请求身份是否已验证
CMS与站点地图	明确计划公开的页面及提交地址	草稿、重复地址和不应索引的页面是否混入

比如本地爬虫返回403，而普通浏览器正常，报告应写“该爬虫请求被拒绝”，再查防火墙或请求条件。没有核实Google请求，就不能把结论扩大成“Google无法访问全站”。同样，访问日志里一条自称Googlebot的User-Agent，也不能单靠名称证明请求身份，需按Google请求验证说明核对。

先确定审计范围，列出应该被搜索到的页面

先记录正式域名、需要检查的子目录、使用的CMS，以及主要页面模板。首页、文章、分类、服务、产品和站内搜索页的用途不同，应分别说明是否希望出现在搜索中。有多语言、参数筛选、登录区域或历史域名时，也要在范围中标明。

接着收集几类URL清单：CMS中的已发布页面、从站内链接抓取到的页面、站点地图里的地址，以及Search Console能够提供的页面记录。这些集合不会天然相同。CMS知道存在但没有内链的页面，抓取工具可能找不到；站点地图里的地址也可能已经跳转或不再需要索引。

清单来源	可以帮助检查什么	不能单独证明什么
CMS已发布URL	网站实际准备公开的内容	访客或谷歌一定能访问
站内链接抓取	从所设入口能够发现的路径	已覆盖全部孤立页或登录内容
XML站点地图	网站提交的候选地址	地址一定被索引或应被索引
Search Console页面记录	谷歌报告中的状态和样本	工具外所有URL的完整实时状态

按正式URL对照这些清单，并保留参数差异，不要一开始就把所有带参数的地址删除。参数可能只是追踪标记，也可能改变产品筛选或分页内容，处理方式需要结合用途判断。发现CMS有而抓取结果没有的页面，先检查是否缺少入口，再确认抓取范围是否漏掉了它。

小站可以尽量覆盖全部公开页面；较大网站先做自动抓取，再按模板、重要性、异常状态和近期改动抽样复核。每种模板选正常页和有疑问的页，才能比较差异。记录抽样依据与没有覆盖的区域，不能检查一个产品页后就宣布全部产品页通过。

可以用下面四条自拟记录练习解释差异。示例中的路径只是说明，没有声称对某个真实网站进行了扫描。

观察到的差异	需要继续查的证据	能成立的下一步
/service/在CMS和地图中，站内抓取没有	来源链接、爬取范围和页面访问	有意公开且无入口时补链；工具漏采先修配置
/old-guide/在地图中，访问后跳转	最终目标与原任务是否一致	确认后让地图和内链使用正确最终地址
/account/在抓取中，但不在地图	页面用途及访问/索引策略	私人账户入口可能是预期排除，不强行加入地图
/products/?page=2只在抓取中出现	分页是否提供不同产品、是否有独立URL	保留真实分页判断，不把所有参数当追踪垃圾删除

这一步的产物应是一份“预期状态已明确”的URL表。后续检查才能区分应当索引却被阻止的页面，与本来就不需要参与搜索的页面。还不知道地图在哪里时，可先按XML Sitemap方法找到实际文件，再回到清单对照。

抓取与响应：入口存在，页面是否真的可访问

在爬虫工具中设置正式起点、需要包含的域名或目录，以及资源和JavaScript处理范围。先保留配置再开始抓取，导出URL、响应码、最终地址和来源链接。若结果只有少量页面，先核对设置和访问限制，不能直接认定网站只有这些内容。

先用Chrome看一条请求：

1. 打开待检查的公开URL，按Ctrl + Shift + I进入开发者工具，选择Network（网络）。
2. 保持工具打开，重新加载页面。点击Doc筛选文档，选中与你当前URL对应的主文档；不要误选图片、脚本或嵌入框架。
3. 在Headers（标头）里记录Request URL和Status Code，再看Response Headers（响应标头）中是否有X-Robots-Tag等指令。
4. 有跳转时保留起始与最终地址。复查刚部署的变化，可在工具打开时启用Disable cache后重载；这不会自动清除服务器或CDN缓存。

保存响应头后，再看HTML里的meta robots和canonical。原始响应与浏览器渲染内容可能不同，涉及JavaScript时按后面的渲染步骤继续核对。Chrome Network操作说明

Google的最低技术要求包括不阻止Googlebot、页面返回成功响应，以及存在可索引内容。满足这些条件只是获得索引资格，并不保证被索引。因此，审计需要同时看实际响应和页面内容。

先检查重要页面的4xx、5xx、重定向链与循环。打开受影响URL，确认最终到达哪里、正文是否正常。已经永久删除且没有替代内容的地址返回404，可以是合理状态；仍被导航或文章推荐的重要资料返回404，则需要修复链接或内容。错误不在于报告里出现了404这个数字，而在于它是否打断应该存在的路径。

再检查robots.txt、服务器与CDN访问规则。浏览器能打开页面，不代表爬虫请求一定被允许；本地爬虫遇到403，也不自动证明Googlebot被同样阻挡。应结合Search Console的URL检查、抓取统计，以及有权限取得的服务器记录定位。没有这些证据时，报告要说明当前只复现了哪一种请求。 若抓取统计已经出现 503，先按主机与报错时段的定位步骤缩小范围，再找主机或 CDN 维护者处理。

robots.txt控制抓取，不是可靠的移除索引工具。Google可能通过外部链接发现被禁止抓取的URL；需要阻止索引时，应选择适合的索引控制或访问保护。robots.txt说明 关于发现路径与重新抓取的基础关系，可以接着看搜索引擎爬虫怎样发现页面。

索引与规范网址：比较预期和实际状态

打开Search Console的页面索引报告，按原因查看样本，并优先核对本来希望参与搜索的重要URL。看到“未编入索引”时，先与页面的预期状态比较。账户页不参与搜索可能是主动选择；服务页被模板意外加上noindex，才是需要处理的错误。

单个URL用URL检查进一步查看：抓取是否允许、索引控制如何、用户声明的规范网址与Google选择的规范网址是否一致。报告与实时测试可能对应不同版本，要记录实际检查时间，避免拿旧状态否定刚部署的修改。

noindex可以通过HTML中的robots标签或HTTP响应头表达，爬虫需要能够读取相应设置。把页面同时禁止抓取，再期待Google看到新加的noindex，可能无法达到预期。robots与X-Robots-Tag说明

规范网址检查则针对重复或非常相似的页面。抽查HTML里的canonical目标、目标页面的响应和索引条件，再核对站点地图、重定向和站内链接是否表达一致的偏好。Google将canonical等方法视为信号，不应把工具发现缺少某标签就直接等同于页面必然无法索引。规范网址说明 推广地址带 UTM 时，可按UTM 链接的 canonical 检查方法核对正式页面。

不要把分页、筛选和不同语言页面统一指向首页来“集中权重”。先确认它们是否提供不同内容、是否需要独立参与搜索，以及应由哪张页面承接。多语言关系可以沿hreflang与canonical配置单独核查；具体“已抓取但尚未索引”问题则交给单URL排查流程，不要只按状态名称猜原因。

把索引检查落到具体响应，通常比只看插件设置更容易发现冲突。下面是自拟教学响应，不是本站检测结果：

HTTP/2 200 Content-Type: text/html; charset=UTF-8 X-Robots-Tag: noindex

假设这是一张准备公开参与搜索的服务页，即使HTML中的robots写着index, follow，也不能因此忽略响应头里的noindex。应先查服务器、CDN或插件为何输出它，再修正产生指令的位置。若同样响应来自不应索引的账户页，则可能符合预期，不需要为了清理工具红色提示而删除控制。

拿一条真实记录作对照：2026年10月8日，我们对本文正式URL作了普通未登录HTTP请求，保存了响应和HTML，结果如下。

当前观察	这次请求的结果
最终URL与状态	本文正式地址，没有跳转，返回200
HTTP索引指令	响应头未发现X-Robots-Tag
HTML robots	max-image-preview:large，这一标签未包含noindex
canonical	指向本文正式地址
主要内容	HTML中有本页标题与正文

这条记录可以帮助排除本次请求中“只有空页面”“响应头禁止索引”“canonical误指别页”等具体故障。它没有证明Google已经索引本文，也不是Googlebot访问记录。你的网站可能输出不同字段，应保留实际结果，不照抄“200、正常”作为验收。

修改索引指令后，用相同未登录条件重查，确认缓存没有继续返回旧输出，再抽查同模板页面。需要查看Google已知的状态时，另用Search Console URL检查。

渲染：核对浏览器与Google拿到的内容

从主要模板中选页面，对照原始HTML、浏览器渲染后的内容，以及Search Console可用的已抓取或实时测试信息。重点寻找主要文字、产品资料、图片说明和重要链接，而不只是确认页面有一个标题。

原始HTML里暂时没有某段文字，不一定说明Google永远看不到它；需要继续检查JavaScript执行后的结果。反过来，自己登录后点开某个标签能够看到内容，也不代表爬虫会完成相同操作。Google的JavaScript SEO说明区分抓取、渲染和索引，并说明被阻止的资源可能影响渲染。

有该站点资源权限时，在GSC检查URL，进入“测试实际网址 → 查看测试网页 → HTML”；没有该资源权限但页面公开可访问时，可以用Rich Results Test输入URL，再从“查看测试网页”读取HTML。后者提供一次测试取到的内容，不能替代该站点的历史索引记录。Google列出的两种查看方式

实际复核时，记录缺失的具体对象，例如“服务项目列表未出现在测试HTML”“分类页下一页只有脚本事件，没有可用链接”。把正常模板和异常模板放在一起比较，再检查相关资源是否失败、内容是否依赖登录或交互，以及接口是否返回了预期数据。

前台看起来完整但工具拿到空内容时，应先确定工具是否启用了所需的渲染方式，不能把工具能力限制写成网站故障。反复出现的模板问题再交给开发处理，并保留复现条件；不要在没有定位之前同时更换主题、插件和缓存配置。

结构与列表：重要内容有没有稳定的发现路径

技术审计还需要覆盖导航、正文链接和列表后续内容。首页、分类或文章中心看起来正常，不代表其下所有页面可达。先检查重要内容是否有真实a链接，再比较公开清单与抓取集合，找到缺少入口或路径异常长的对象。

对分页与“加载更多”，抽查第一页之外的内容。浏览器点按钮能出现后续卡片，不能单独证明爬虫会执行同样交互。后续列表应有可发现的路径和正确目标，不能全部返回同一份第一页内容，也不应把真实分页全部规范到第一页。Google分页说明 想自己走一遍，可以用分类分页检查教程核对第二页、后续页与详情页的实际地址。

筛选、排序和跟踪参数需要分开处理。记录参数是否改变内容、是否需要独立搜索入口，以及当前链接和canonical怎样表达。不要先删除所有问号后面的内容，再宣布URL已经去重；那样可能把不同的分页或产品状态混成一条。

发现模板只输出部分产品时，修复列表查询或分页比给每个遗漏产品单独加临时链接更合适。根因与个别补救应在审计单上分开，避免新增内容继续复现相同问题。

再查移动体验、性能与适用的扩展

移动端内容与操作

按模板检查移动端的主要内容、菜单、表格、按钮和表单。桌面端存在而移动端完全缺失的重要说明，需要核实；内容只是放在正常可访问的折叠区，与根本没有提供内容不同。应检查真实输出及可用性，不按外观猜索引结果。

性能数据与具体资源

性能方面，先看Search Console核心网页指标或PageSpeed Insights能够提供的真实用户数据，再用实验室诊断定位资源问题。LCP、INP、CLS分别涉及加载、响应和视觉稳定性；具体指标与推荐范围可以查Google核心网页指标说明。

使用PageSpeed Insights时，确认显示的是当前URL还是整个来源的数据，并记录设备及测试环境。真实用户数据反映历史体验，实验室测试用于可控环境下的诊断，两者可能不同。没有足够真实用户样本时，保留这一限制，不把“暂无数据”当成已经通过。PageSpeed Insights数据说明

发现问题后再检查大图、第三方脚本、字体、服务端响应或布局变化等具体原因。提高一次实验室分数不能代替表单、菜单和业务功能正常工作；修改资源加载方式后，应把这些功能一起复查。

结构化数据与可见内容

结构化数据按页面实际类型检查。产品、文章或其他标记应与可见内容一致，使用Rich Results Test核对它支持的类型，同时区分错误与建议项。

结构化数据不能只验语法。文章作者、商品价格或其他字段要与页面可见内容和实际对象相符；一个合法JSON不代表标记内容真实，富媒体测试通过也不保证最终显示。没有适用类型的页面，不必为了工具检查项完整而强行添加。Google结构化数据准则

多语言页面的对应关系

多语言网站则按一组对应页面检查，不能只挑中文页看有没有hreflang。先确认每个语言URL实际公开、内容语言正确且对应同一任务，再检查相互指向与规范地址。语言切换若把所有内页都送到对方首页，读者任务也会中断。只有单一语言的网站，把这项标记为不适用即可，不需要增加不存在的语言版本。

按影响范围与证据安排修复

工具可以报告数百条相似警告，但修复顺序要看影响了哪些页面、是否阻止主要任务、证据是否充分，以及是否有共同原因。同一个模板误伤一组重要服务页，通常比一张历史文章图片尺寸略大更值得先处理。

下面是自拟的判断示例，不代表本站扫描结果。相同技术信号可能对应不同决定。

观察到的信号	核对后的情况	处理方向
页面包含noindex	本来就不希望账户页进入搜索	记录为预期状态，保留控制
页面包含noindex	正式服务模板误用了测试设置	先修模板并复核受影响服务页
报告出现404	下线资料没有替代页，也没有误导入口	接受实际状态，检查残留链接
报告出现404	主导航仍推荐这张重要页面	修复入口或恢复正确内容
实验室性能较差	单次测试异常，真实范围不明	复测并定位原因后排期

优先级记录需要写出理由，例如“影响准备获得搜索流量的服务模板，当前可复现索引阻断”。不要只写“高优先级：SEO有问题”。有明确访问或索引阻断的关键页面先处理，之后再安排渲染、路径和体验问题；纯建议项可以结合成本与功能风险排期。

交付后要能复查，才算完成审计

每项问题至少记录：样本URL、页面类型、预期状态、实际状态、证据与检查时间、影响范围、建议修改、负责人及验证方式。截图有助于沟通，但响应码、HTML字段和可复现步骤往往更适合技术交接。

例如，不只写“修复canonical”，而是写清哪些页面指向了哪个错误目标，正确目标应是什么，谁负责模板输出，部署后如何抽查。遇到无法确认的部分，单独列出待取得的日志或权限，避免开发把假设当成已经定位的故障。

修复后，用相同条件重查原样本，再抽查同模板其他页面。当前输出正确，可以标记为部署验证通过；Google尚未重新处理的状态则继续观察。不要要求开发用当天排名上涨证明修复成功，也不要因为排名尚未变化就反复改同一设置。

将前面自拟的服务页noindex问题写成工单，可以具体到下面这个程度。它示范交付方式，不是某个真实网站的检测报告。

工单字段	教学填写示例
对象与预期	正式服务页https://example.com/service/，计划公开参与搜索
复现条件	未登录请求主文档，保存时间、响应头与HTML；避免仅看后台预览
观察结果	返回200且有正文；响应头出现X-Robots-Tag: noindex，HTML设置与之不一致
已知范围	当前确认一个样本；同模板其他服务页待批量检查，不先填写全站受影响
修复负责人	能修改产生该响应头的服务器、CDN或插件配置的负责人
建议动作	定位指令来源并修复错误范围，保留账户页等必要排除，不全站删除所有noindex
当前验收	原样本和同模板样本输出符合各自预期，页面与业务功能仍正常
后续观察	记录部署时间，等待Google重新抓取处理，再看URL检查中的最新状态

这张工单把发现、假设和待确认范围分开。开发不需要猜“SEO修复”具体指什么，也不用拿当天排名作为验收条件。若后续发现指令只来自某个缓存节点，再更新范围与复现条件，而不是保留一个已经过时的“全模板故障”结论。

审计完成意味着范围、发现和下一步都清楚，不代表网站以后不会再出问题。主题升级、模板调整、迁移和重要功能上线后，可复查相关部分；上线项目另配合WordPress上线检查。学习顺序可从谷歌SEO学习路径继续展开。