首页 / SEO book / 其他精选 / 常见的 SEO 技术问题与修复

10 个真正重要的 SEO 问题及修复方法

常见的 SEO 技术问题与修复其他精选

令人意外的是,出现频率最高的问题未必就是那些让你寝食难安的问题。它们或许值得修复,但绝对不该排在待办清单的最前面。例如,我们发现被研究的网站中有 72.9% 缺少元描述……

去年,我们深入研究了一项覆盖超过一百万个域名的研究,以找出最常见的 SEO 技术问题。

令人意外的是,出现频率最高的问题未必就是那些让人寝食难安的问题。它们或许值得修复,但绝对不该排在待办清单的最前面。

例如,我们发现被研究的网站中有 72.9% 缺少元描述(meta description),但元描述并不影响排名,而且在这种情况下 Google 也会自动生成一段。相反,规范页(canonical)指向已损坏页面这种严重问题,只出现在 2.6% 的网站上。

因此,若想修复那些会严重影响排名的问题,这里有一个更好的办法:使用免费的 Ahrefs Webmaster Tools 和 Google Search Console,查看你的网站是否受到本文列出的九个问题中的任何一个影响。

继续阅读,了解这些问题为何重要,以及如何利用这些工具找到并修复它们。

更新:2026 年 2 月,Google 更新了文档,说明Googlebot 只会抓取受支持文件类型的前 2 MB 内容,包括 HTML,超出限制的内容都会被忽略。这对多数网站不太可能造成影响,但一旦发生就是严重问题,因此我把它加入了这份清单。

1. 可索引性问题

可索引性是指网页被搜索引擎索引(收录)的能力。视具体问题而定,Google 可能索引错误的页面,或无法在搜索结果页(SERP)中展示该页面(这样这些页面就拿不到任何流量)。

以下是这类问题的一些例子:

  • 规范标签指向 4XX —— 只有有效且可访问的 URL 才应被指定为规范页。当搜索引擎爬虫无法访问所指定的规范页时,该指令就会被忽略,错误的(非规范的)页面版本就可能被索引。
  • 规范标签指向重定向 —— 网站中相似或重复的页面必须指定规范页,以指示搜索引擎在搜索结果中展示最具权威性(规范)的页面版本。

一个页面要被索引,必须满足三个条件:

  1. 页面必须可以被抓取。如果你没有阻止 Googlebot 进入该页面 robots.txt,或者你的网站页面数少于 1,000 个,那么你大概不存在这方面的问题。
  2. 页面不能带有 noindex 标签(稍后会详细说明)。
  3. 页面必须是规范页(即主要版本)。

如何修复

注册一个免费的 Ahrefs Webmaster Tools 账户并设置项目(只需点击几下即可完成)。接下来:

  1. 打开 Site Audit。
  2. 进入 Indexability(可索引性)报告。
  3. 点击与规范化和 "noindex" 相关的问题,查看受影响的页面。
Ahrefs 的 Site Audit 中的可索引性问题。

对于这份报告中的规范化问题,需要把 link rel="canonical" 标签中的无效 URL 替换为有效 URL(即返回 "HTTP 200 OK" 的 URL)。

至于被 "noindex" 问题标记的页面,它们是在代码中放置了 "noindex" 元标签的页面。报告中发现的大多数页面很可能应保持原样。但若看到任何本不该如此设置的页面,只需移除该标签即可,不过请先确认这些页面没有被 robots.txt 屏蔽。

点击右侧的问号,即可查看每个问题的修复说明。如需更详细的说明,可点击 “Learn more” 链接。

canonical 指向重定向问题的详情。

2. 损坏页面

损坏页面是指网站上返回 4XX 错误(无法找到)和 5XX 错误(服务器错误)的页面。这些页面要么不会被 Google 索引,要么会从索引中被移除;无论哪种情况,都可能损失流量,并给访客带来糟糕的体验。

此外,若损坏页面上还有反向链接(外链)指向它,那么所有这些链接权重都会白白浪费。

损坏页面还会浪费抓取预算,在大型网站上尤其需要注意。

如何修复

在 AWT 中,你应当:

  1. 打开 Site Audit。
  2. 进入 Internal pages(内部页面)报告。
  3. 查看是否存在损坏页面。如果有,Broken(损坏)分区会显示一个大于 0 的数字。点击该数字即可显示受影响的页面。
Site Audit 中的内部页面报告。

在显示存在问题的页面的报告中,最好添加一列 “引用域名数量”,这有助于决定如何修复。

向报告添加一列。

修复损坏页面(4XX 错误代码)其实相当简单,但有不止一种处理方式。下面这张简图说明了整个流程:

如何处理失效链接——流程图。

处理服务器错误(即报告 5XX 的错误)可能更棘手,因为服务器无响应的原因有多种可能。可阅读这篇简短指南进行排查。

借助 AWT,你还可以看到由指向网站的错误链接所导致的 404。虽然这本身算不上技术问题,但找回这些链接可能为 SEO 带来额外提升。

  1. 前往 Site Explorer
  2. 输入你的域名
  3. 进入 Best by links(按链接排序的最佳页面)报告
  4. 添加一个 “404 not found” 过滤器
  5. 然后按引用域名数量从高到低对报告排序
如何找到指向你网站的失效反向链接。

内链是指指向同一网站上页面或资源的任何超链接,它们可以通过以下方式影响排名:

  • 帮助像 Google 这样的搜索引擎发现并抓取页面
  • 通过从更强势页面传递下来的 PageRank(又称链接权重或链接权益)来提升页面。

在最糟糕的情况下,想要排名的页面可能没有任何内链。这类页面被称为孤立页面(orphan pages):网络爬虫访问它们的能力有限(只能通过站点地图或外链),也没有任何链接权重从网站的其他页面流向它们。

更常见的情况是,若一些页面拥有更多相关的链接,它们本可以排得更高,或为更多关键词获得排名。

如何修复

  1. 前往 Site Audit。
  2. 打开 Links(链接)报告。
  3. 打开 Issues(问题)标签页。
  4. 滚动到 Indexable(可索引)类别。
Site Audit 中的孤岛页面问题。

孤立页面要么需要从网站的其他某个页面链接过来,要么在该页面对你毫无价值时删除。

至于内链机会,AWT 会自动识别:

  1. 前往 Site Audit。
  2. 打开 Internal link opportunities(内链机会)工具。
Site Audit 中的内部链接机会。

在文档中重点关注标记为 “source page” “keyword context” 和 “target page” 的列,它们会指导你从哪个网页添加链接、链接到哪个网页,以及链接应添加在页面上的具体位置。

例如,我们可以在 SEO 统计数据清单中添加几个相关的内链:

内部链接机会示例。

4. 移动端体验问题

拥有一个对移动端友好的网站是 SEO 的必备条件,原因有两个:

  1. Google 采用移动优先索引 —— 它主要使用移动端页面的内容来索引和排列页面。
  2. 移动端体验是页面体验信号的一部分 —— 尽管据说 Google 始终会 “优先” 展示内容最好的页面,但当页面内容质量相近时,页面体验可能成为决定性因素。

以下是这类问题的一些例子:

  • 未设置视口(Viewport) —— 当页面缺少 [['Text', '<meta name=“viewport”>']] 的 [['Text', 'tag']] 或 [['Text', 'width']] 或 [['Text', 'initial-scale']] 参数时。
  • 点击目标过小或过于密集 —— 当交互元素不够大,或其可点击区域相互重叠时。
  • 文档使用了插件 —— 当页面需要 Java 或 Flash 之类的插件时。

如何修复

在 Ahrefs Site Audit 中,可在 Usability and performance(可用性与性能)类别下查找这些问题。

可用性和性能问题列表。

接下来,点击问题名称旁边的问号,并按说明为受影响的页面解决这些问题(这需要一些 Web 开发工作)。

移动端易用性问题详情。

例如,若该工具发现某些页面的字体对移动设备而言过小,需要确保视口标签设置正确,并将字体调至至少 12 px。

5. HTTPS 问题

Google 将 HTTPS 加密作为一个轻微的排名信号,这意味着若没有 TLS 证书保护网站安全,可能遭遇排名下降。

但即使拥有证书,页面上的某些页面和/或资源仍可能使用 HTTP 协议。

如何修复

假设你已经为所有子域名配置了 SSL/TLS 证书(若没有,请务必配置),打开 AWT 并执行以下操作:

  1. 打开 Site Audit
  2. 进入 Internal pages(内部页面)报告
  3. 查看协议分布图,并点击 HTTP 查看受影响的页面
  4. 在显示页面的报告中,添加一列 Final redirect URL(最终重定向 URL)
  5. 确保所有 HTTP 页面都永久重定向(301 或 308 重定向)到对应的 HTTPS 页面
HTTPS 问题报告。
添加最终的跳转列。

最后,我们来检查网站上是否还有资源仍在使用 HTTP:

  1. 在 Internal pages 报告中,点击 Issues(问题)。
  2. 然后点击 HTTPS/HTTP mixed content(HTTPS/HTTP 混合内容),查看受影响的资源。
HTTPS/HTTP 混合内容问题。

最快的修复方法是在 .htaccess 文件或服务器配置中添加这段简短的代码。

该配置可以确保每当浏览器向服务器请求页面或资源时,任何 HTTP 请求都会被自动转换为 HTTPS,以增强安全性。

6. 性能与稳定性问题(核心网页指标)

Google 的核心网页指标(Core Web Vitals,CWV)是一组旨在衡量网站用户体验的指标,主要体现在加载速度和响应速度方面。它们是 Google 页面体验信号的一部分,会影响搜索引擎排名。

话虽如此,从 SEO 角度看,目标并不是成为最快的网站或 “最易用” 的网站,而是至少在这三个类别中达到 “良好(good)”:

  • 最大内容绘制(LCP)。它衡量的是在你请求网页后,屏幕上最大的内容元素(如图片、视频或大块文本)完全加载所需的时间。这是访客能看到页面内容有多快的关键指标。
  • 交互到下一次绘制(INP)。它评估页面响应用户操作的灵敏程度,衡量页面响应点击、轻触和按键操作所需的时间。INP 值反映的是这些交互中最长的响应时间(排除极端情况)。该指标于 2024 年 3 月取代了 首次输入延迟(FID)。
  • 累积布局偏移(CLS)。CLS 会累计页面加载过程中页面元素所有意外的移动。数值越高表示偏移越多,这会让试图阅读或与页面交互的用户感到烦躁。该指标有助于识别并尽量减少这些偏移,从而改善用户体验。

如何修复

检查整个网站 CWV 最快的方法,大概是使用免费的 Google Search Console。

  1. 在报告的 Experience(体验)部分点击 Core Web Vitals。
  2. 在每个部分点击 Open report(打开报告),查看你网站的得分情况。
  3. 对于不被视为良好的页面,你会在报告底部看到一个特殊部分。用它来查看需要你关注的页面。
Google Search Console 中的 Core Web Vitals 报告。
CWV 报告详情。

针对 CWV 进行优化可能需要一些时间和 Web 开发技能,例如迁移到更快(或更近)的服务器、压缩图片、优化 CSS 等。我们在这份 CWV 指南的第三部分中讲解了具体做法。

7. 未优化的网站结构

在技术 SEO 的语境下,未优化的网站结构主要指重要的自然流量页面在网站结构中层级过深。

嵌套过深的页面(用户从首页出发需要点击超过 6 次才能到达)从首页(很可能是拥有最多反向链接的页面)获得的链接权重更少,这可能影响其排名。这是因为链接价值会随着每一次链接 “跳转” 而递减。

网站结构之所以重要还有其他原因,例如整体用户体验、抓取效率,以及帮助 Google 理解页面的上下文。这里我们只聚焦技术层面,你可以在我们的完整指南中阅读更多相关内容:网站结构:如何构建你的 SEO 基础。

如何修复

  1. 打开 Site Audit,进入 Structure Explorer(在左侧菜单中)。
  2. 将 Segment(分组)配置为仅 valid HTML pages(有效 HTML 页面),然后点击 Apply(应用)。
在 Site Audit 中应用细分筛选器。
  1. 切换到 Depth(深度)标签页,并将数据类型设置为 Data table(数据表)。
  2. 使用图表来排查距离首页超过六次点击的页面。
切换到深度(depth)标签页。

解决这个问题的办法是从更靠近首页的页面链接到嵌套较深的页面。更重要的页面可以放入网站导航,不太重要的页面则只需从靠近几层点击的页面链接过去即可。

在决定哪些内容放入全站导航时,最好权衡用户体验和网站的业务角色。

例如,我们本可以把SEO 术语表放入主导航,从而略微提高它领先于自然搜索竞争对手的几率,但我们决定不这么做,因为对于那些并非专门搜索此类信息的用户来说,它并不是那么重要的页面。

取而代之,我们只是把术语表提升了一个层级,在 SEO 新手指南(它本身距离首页仅一次点击)中加入了一个链接。

显示距首页仅一次点击的页面的报告。
内部链接示例。

8. 缺少相关的结构化数据标记

结构化数据标记(Schema markup)是一种帮助 Google 理解页面信息的代码,可用于展示富媒体搜索结果(又称富媒体摘要)。

结构化数据标记不是排名因素,也无法让你在文本搜索结果中排名更高。

不过,结构化数据标记可以让页面有资格出现在富媒体搜索结果中。对于某些搜索查询,Google 会把这些结果展示在搜索结果页中非常显眼的位置,有些甚至出现在标准文本结果的上方。

富媒体结果示例。

对于包含以下类型内容的页面,这尤为重要:

  • 食谱。
  • 招聘广告。
  • 视频。
  • 新闻文章。
  • 关于活动的信息/活动落地页。
  • 电影详情。

如何修复

有多种方法可以免费生成和验证结构化数据:可以使用 Merkle 或 Schema 之类的工具,也可以用 ChatGPT 半自动化地完成这一过程。

这里值得特别提一下 ChatGPT,因为它能为任何页面识别出相关类型的结构化数据。若页面已上线,只需粘贴 URL;若尚未上线,就上传文案,再让 AI 生成结构化数据。可以使用以下提示词:

接着复制代码,并用 Google 的富媒体搜索结果测试跑一遍,确认一切无误。

使用 ChatGPT 生成 schema。

最后,将代码应用到页面上。若使用的是 WordPress 或 Wix 之类的流行 CMS,可以找一个结构化数据标记插件/应用;否则,可能需要手动把代码添加到每个符合条件的页面。

也可以使用 AWT 查找整个网站上的任何结构化数据问题,可在 All issues report(所有问题报告)的 Others(其他)部分找到这些问题。

Site Audit 报告的结构化数据错误。

9. 重复内容

当完全相同或近乎重复的内容出现在网络上的多个位置时,就构成了重复内容。

在出现重复内容的情况下,Google 会从中选择一个页面展示在搜索结果页中,但它未必是你希望被索引的那个页面。

内容重复并不一定源于故意或无意创建了相似页面,还有一些不那么明显的原因,例如分面导航、URL 中的跟踪参数,或使用了带斜杠与不带斜杠的 URL。

如何修复

首先,检查网站是否只能通过一个 URL 访问。如果网站可以通过以下地址访问:

  • http://domain.com
  • http://www.domain.com
  • https://domain.com
  • https://www.domain.com

……那么 Google 会把所有这些 URL 视为不同的网站。

检查用户是否只能浏览网站的一个版本,最简单的方法是在浏览器中逐一输入这四种变体,按回车,看看它们是否会被重定向到主版本(理想情况下是带有 HTTPS 的那个)。

也可以直接进入 Site Audit 的 Duplicates(重复项)报告。若看到 100% 的不良重复项,那很可能就是原因所在。

Site Audit 中的重复内容分布报告。

在这种情况下,选择一个版本作为规范页(很可能是带有 HTTPS 的那个),并将其他版本永久重定向到它。

然后在 Site Audit 中运行一次 New crawl(新抓取),看看是否还留有其他不良重复项。

在 Site Audit 中启动新的抓取。

根据具体情况,有几种处理不良重复项的方法,可在我们的指南中了解如何解决它们。

10. 体积过大的 HTML 页面

Googlebot 只会处理一个页面原始(未压缩)HTML 的前 2 MB,之后的所有内容都会被忽略。对多数页面来说,2 MB 绰绰有余,但带有大量内嵌 CSS/JS 等内容且未经优化的页面,可能在无人察觉的情况下超限:浏览器能正常渲染所有内容,但 Googlebot 会悄悄停止读取。

这意味着体积过大页面底部附近的内容、链接和结构化数据可能永远无法被索引。

如何修复

可借助免费的 Ahrefs Webmaster Tools 检查网站是否存在这个问题:打开 Site Audit,进入 All issues,查找 “Page size exceeds Googlebot's 2 MB crawl limit”(页面大小超过了 Googlebot 2 MB 的抓取上限)。

HTML 过大问题——在 Site Audit 中的位置。

通过处理最常见的元凶,把未压缩的 HTML 控制在 2 MB 以下:

  • 内联的 base64 图片。把它们替换为普通的外部图片文件。
  • 内嵌的 SVG 和大型 JSON 代码块。把它们移到单独的文件中,或加以简化。
  • 内联的 CSS 和 JavaScript。把它们移到外部 [['Text', '.css']] 和 [['Text', '.js']] 文件中。
  • 臃肿的标记。CMS 主题和页面构建器经常会注入冗余的 HTML。检查源代码并清理。

结语

修复完更紧迫的问题之后,再深入挖掘一下,让网站保持理想的 SEO 健康状态。打开 Site Audit 并进入 All issues 报告,查看其他关于站内 SEO、图片优化、重定向、本地化等方面的问题,每个问题都能找到相应的处理说明。

如何在 Site Audit 中自定义问题报告。

有些问题,例如可索引性问题,可以直接在 Site Audit 中使用 Patches(补丁)功能修复(它属于 Project Boost Max 附加组件的一部分),无需在 CMS 之间不停切换窗口,也不必依赖开发人员。若正在处理大型网站或管理多个客户,值得考虑使用。

例如,这里可以看到直接在 Site Audit 中修复博客文章标题,甚至可以请 AI 提供建议。

我是否遗漏了任何重要的技术问题?欢迎在 X 上或在 LinkedIn 上告诉我。