目录[-]

技术SEO是什么？简单说：让搜索引擎能找到你的页面、能读懂你的内容、能正确索引你的网站。

很多人觉得技术SEO很神秘。一堆代码、一堆配置、一堆看不懂的术语。

其实不是。技术SEO的核心逻辑很简单：Google是一个机器人，它需要爬取你的网站、理解你的内容、把你的页面存到它的数据库里。你的工作就是让这个过程尽可能顺畅。

如果Google爬不到你的页面，你的内容再好也没用。如果Google读不懂你的页面结构，它就不知道该把你排在哪里。如果你的网站速度慢、移动端体验差，Google会直接降低你的排名。

根据SEMrush的研究，超过80%的网站存在技术SEO问题。这些问题中，很多是基础性的——robots.txt配置错误、Canonical标签缺失、页面速度过慢。

这篇文章会从最底层的爬虫机制讲起，一直讲到最前沿的AI搜索优化。不管你是刚入门的新手，还是有经验的SEO从业者，都能找到有用的东西。

我们开始。

技术SEO的底层逻辑：爬取、渲染、索引

在讲具体操作之前，先搞清楚Google是怎么工作的。

第一步：爬取（Crawling）

Google有一个叫Googlebot的爬虫程序。它的工作就是不停地访问网页，抓取页面内容。

Googlebot怎么发现新页面？

  • 通过已知页面上的链接

  • 通过XML Sitemap

  • 通过Google Search Console手动提交

  • 通过第三方网站上指向你的链接

Googlebot发现一个URL后，会把它加入爬取队列。但不是所有URL都会被立即爬取。Google会根据页面的重要性、更新频率、网站的爬取预算来决定爬取优先级。

第二步：渲染（Rendering）

爬取到HTML后，Google需要渲染页面——执行JavaScript、加载CSS、生成最终的DOM。

这一步很关键。如果你的网站大量依赖JavaScript来生成内容（比如React、Vue、Angular单页应用），Google需要额外的时间和资源来渲染。根据Google官方文档，渲染可能会延迟几秒到几天不等。

第三步：索引（Indexing）

渲染完成后，Google会分析页面内容，提取关键信息（标题、正文、链接、结构化数据等），然后决定是否把这个页面加入索引。

索引就是Google的数据库。只有被索引的页面才能出现在搜索结果中。

整个流程：

发现URL → 加入爬取队列 → 爬取HTML → 渲染页面 → 分析内容 → 加入索引 → 参与排名

技术SEO的目标就是确保这个流程的每一步都顺畅。、

 

Robots.txt：控制爬虫的第一道门

Robots.txt是放在网站根目录的一个文本文件（example.com/robots.txt）。它告诉搜索引擎爬虫：哪些页面可以爬，哪些不可以。

基本语法

User-agent: *
Disallow: /admin/
Disallow: /cart/
Disallow: /checkout/
Allow: /
Sitemap: https://example.com/sitemap.xml

解释：

  • User-agent: *

     — 对所有爬虫生效

  • Disallow: /admin/

     — 禁止爬取/admin/目录下的所有页面

  • Allow: /

     — 允许爬取其他所有页面

  • Sitemap:

     — 告诉爬虫Sitemap的位置

 

常见的Robots.txt错误

错误

后果

正确做法

Disallow: / （禁止所有爬取）

整个网站从搜索结果消失

只禁止不需要索引的目录

屏蔽CSS/JS文件

Google无法渲染页面，影响排名

允许爬取CSS和JS

屏蔽图片目录

图片无法出现在Google图片搜索

允许爬取图片

开发环境忘记修改

上线后整站被屏蔽

上线前检查robots.txt

用Robots.txt阻止索引

页面仍可能被索引（只是不被爬取）

用noindex标签阻止索引

最后一点特别重要：Robots.txt只能阻止爬取，不能阻止索引。如果其他网站链接到你的某个页面，Google可能会在不爬取的情况下索引这个URL（只显示URL，没有内容摘要）。要真正阻止索引，必须用noindex标签。

不同平台的Robots.txt

WordPress：默认自动生成robots.txt，可以通过Rank Math或Yoast SEO插件自定义。

Shopify：自动生成robots.txt，不能直接编辑文件。但从2021年开始，可以通过robots.txt.liquid模板做有限的自定义。

自定义网站：手动创建robots.txt文件，放在网站根目录。

AI爬虫的Robots.txt

2024-2025年，AI爬虫成了新问题。OpenAI的GPTBot、Anthropic的ClaudeBot、Google的Google-Extended——这些AI爬虫会抓取你的内容用于训练模型。

如果你不想让AI爬虫抓取你的内容：

User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Google-Extended
Disallow: /

但要注意：屏蔽AI爬虫可能会影响你在AI搜索结果中的可见性。这是一个权衡。

 

XML Sitemap：给Google一张地图

XML Sitemap是一个列出网站所有重要页面的文件。它帮助Google发现和理解你的网站结构。

Sitemap不是排名因素。有Sitemap不会让你排名更高。但它能确保Google知道你所有重要页面的存在。

Sitemap的基本格式

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.com/page-1/</loc>
    <lastmod>2025-01-15</lastmod>
    <changefreq>monthly</changefreq>
    <priority>0.8</priority>
  </url>
</urlset>

其中：

  • loc

    ：页面URL（必填）

  • lastmod

    ：最后修改日期（推荐填写，Google会参考）

  • changefreq

    ：更新频率（Google基本忽略这个字段）

  • priority

    ：优先级（Google也基本忽略）

所以实际上，你只需要关注loc和lastmod。

Sitemap最佳实践

规则

说明

只包含需要索引的页面

不要把noindex页面、重定向页面、404页面放进Sitemap

Sitemap中的URL必须是Canonical URL

如果一个页面有Canonical标签指向另一个URL，Sitemap里应该放Canonical URL

每个Sitemap最多50,000个URL

超过的话用Sitemap Index文件拆分

Sitemap文件大小不超过50MB

压缩后提交（.xml.gz）

lastmod要准确

只在页面内容真正更新时才改lastmod，不要每天自动更新所有页面的lastmod

在robots.txt中声明Sitemap位置

Sitemap: https://example.com/sitemap.xml

在Google Search Console中提交

提交后可以看到索引状态

 

大型网站的Sitemap策略

如果你的网站有几万甚至几十万个页面，需要用Sitemap Index文件来组织：

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://example.com/sitemap-products.xml</loc>
    <lastmod>2025-01-15</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://example.com/sitemap-categories.xml</loc>
    <lastmod>2025-01-10</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://example.com/sitemap-blog.xml</loc>
    <lastmod>2025-01-14</lastmod>
  </sitemap>
</sitemapindex>

按页面类型拆分Sitemap（产品、分类、博客、静态页面），方便管理和监控。

不同平台的Sitemap

WordPress + Rank Math：自动生成Sitemap，可以在Rank Math设置里控制哪些内容类型包含在Sitemap中。路径通常是 /sitemap_index.xml。

Shopify：自动生成Sitemap，路径是 /sitemap.xml。不能自定义，但Shopify的默认Sitemap已经够用。

自定义网站：用工具生成（Screaming Frog、Sitebulb），或者用代码动态生成。

Canonical标签：解决重复内容的利器

重复内容是技术SEO最常见的问题之一。同一个内容出现在多个URL上，Google不知道该索引哪个。

Canonical标签告诉Google：这些重复页面中，哪个是"正版"。

什么时候需要Canonical标签

常见的重复内容场景：

  • URL参数

    ：example.com/product 和 example.com/product?ref=email 是同一个页面

  • HTTP/HTTPS

    ：http://example.com 和 https://example.com

  • www/non-www

    ：www.example.com 和 example.com

  • 尾部斜杠

    ：example.com/page 和 example.com/page/

  • 大小写

    ：example.com/Page 和 example.com/page

  • 分页

    ：example.com/blog 和 example.com/blog?page=1

  • 排序/筛选

    ：example.com/products?sort=price 和 example.com/products?sort=name

  • 跨域内容

    ：你的文章被其他网站转载

 

Canonical标签的用法

在页面的<head>中添加：

<link rel="canonical" href="https://example.com/preferred-url/" />

每个页面都应该有Canonical标签，包括自引用的Canonical（指向自己）。

Canonical标签的常见错误

错误

后果

正确做法

所有页面Canonical指向首页

除首页外所有页面从索引消失

每个页面指向自己的Canonical URL

Canonical URL是404页面

Google忽略Canonical标签

确保Canonical URL返回200

Canonical URL被robots.txt屏蔽

Google无法验证Canonical

确保Canonical URL可以被爬取

Canonical链条（A→B→C）

Google可能忽略

直接指向最终URL

Canonical和noindex同时使用

信号矛盾，Google困惑

二选一：要么Canonical到正版，要么noindex

HTTP Canonical在HTTPS页面上

协议不一致

Canonical URL使用HTTPS

重要提示：Canonical标签是"建议"，不是"指令"。Google可能会忽略你的Canonical标签，选择它认为更合适的URL作为Canonical。如果你发现Google选择了错误的Canonical，需要检查内链、Sitemap、外链是否都指向正确的URL。

网站架构和URL结构

网站架构决定了Google如何理解你的网站。好的架构让Google轻松爬取所有页面；差的架构让Google迷路。

扁平化架构

理想的网站架构是扁平的——任何页面都能在3次点击内从首页到达。

首页
├── 分类A
│   ├── 产品A1
│   ├── 产品A2
│   └── 产品A3
├── 分类B
│   ├── 产品B1
│   └── 产品B2
└── 博客
    ├── 文章1
    └── 文章2

层级太深的问题：

  • Google爬虫可能爬不到深层页面

  • 深层页面获得的内链权重（PageRank）更少

  • 用户找不到深层内容

     

URL结构最佳实践

URL是技术SEO的基础。好的URL结构：

原则

好的URL

差的URL

简短

/ball-valves/

/products/category/industrial/ball-valves/stainless-steel/

描述性

/stainless-steel-ball-valve/

/product-12345/

用连字符分隔

/ball-valve/

/ball_valve/ 或 /ballvalve/

小写

/ball-valve/

/Ball-Valve/

不含参数

/ball-valves/

/products?cat=5&sort=price

包含关键词

/link-building-guide/

/post-2025-01-15/

URL变更和重定向

URL一旦确定，尽量不要改。每次改URL都需要设置301重定向，而且会有短期的排名波动。

如果必须改URL：

  1. 设置301重定向（永久重定向）从旧URL到新URL

  2. 更新所有内链指向新URL

  3. 更新Sitemap

  4. 在Google Search Console中监控

  5. 保持301重定向至少一年

301 vs 302重定向：

  • 301

    ：永久重定向。告诉Google旧URL已经永久移动到新URL，权重会传递。

  • 302

    ：临时重定向。告诉Google旧URL只是暂时跳转，权重不传递（或传递很少）。

大多数情况下，你应该用301。只有在页面真的是临时移动（比如A/B测试、临时维护）时才用302。

页面速度与Core Web Vitals

2021年，Google正式把Core Web Vitals纳入排名因素。页面速度不再只是"最好有"，而是"必须有"。

三个核心指标

指标

衡量什么

好

需改进

差

LCP（Largest Contentful Paint）

最大内容元素的加载时间

≤2.5秒

2.5-4秒

>4秒

INP（Interaction to Next Paint）

用户交互到页面响应的延迟

≤200ms

200-500ms

>500ms

CLS（Cumulative Layout Shift）

页面加载过程中的布局偏移

≤0.1

0.1-0.25

>0.25

注意：2024年3月，Google用INP（Interaction to Next Paint）替代了FID（First Input Delay）。INP衡量的是整个页面生命周期中所有交互的响应速度，比FID更全面。

LCP优化

LCP通常是页面上最大的图片或文本块。优化LCP的方法：

  • 优化服务器响应时间（TTFB）

    ：用好的主机、启用缓存、用CDN

  • 优化最大内容元素

    ：如果LCP元素是图片，压缩图片、用WebP格式、设置正确的尺寸

  • 预加载LCP资源

    ：<link rel="preload" as="image" href="hero.webp">

  • 减少渲染阻塞资源

    ：内联关键CSS、延迟非关键JS

  • 避免客户端渲染

    ：如果LCP内容需要JS才能显示，考虑服务端渲染

 

INP优化

INP衡量的是页面对用户交互的响应速度。点击按钮、输入文字、选择下拉菜单——这些交互后，页面多快能给出视觉反馈？

优化INP：

  • 减少主线程阻塞

    ：拆分长任务（Long Tasks），用requestIdleCallback或scheduler.yield()

  • 减少JavaScript执行时间

    ：删除不必要的JS、延迟加载第三方脚本

  • 优化事件处理器

    ：避免在事件处理器中做复杂计算

  • 减少DOM大小

    ：DOM节点越多，交互响应越慢

 

CLS优化

CLS衡量的是页面加载过程中元素的意外移动。你正在读一段文字，突然一个广告加载出来，把文字推下去了——这就是布局偏移。

常见的CLS问题和解决方案：

问题

原因

解决方案

图片加载导致偏移

图片没有设置宽高

给img标签设置width和height属性

广告加载导致偏移

广告位没有预留空间

给广告容器设置固定尺寸

字体加载导致偏移

Web字体替换系统字体时大小不同

用font-display: swap + 匹配的fallback字体

动态内容插入

JS加载后插入内容

预留空间或用CSS contain

iframe加载

iframe没有设置尺寸

给iframe设置固定宽高

测量工具

测量Core Web Vitals的工具：

  • Google PageSpeed Insights

    ：最常用，同时显示实验室数据和真实用户数据

  • Google Search Console

    ：Core Web Vitals报告，显示整站的CWV状态

  • Chrome DevTools

    ：Performance面板，详细的性能分析

  • Web Vitals Chrome扩展

    ：实时显示当前页面的CWV数据

  • Lighthouse

    ：Chrome内置的审计工具

重要区分：实验室数据（Lab Data）和真实用户数据（Field Data）。

  • 实验室数据

    ：在模拟环境中测量，每次结果可能不同，用于调试

  • 真实用户数据（CrUX）

    ：来自真实Chrome用户的数据，这才是Google用来排名的数据

如果你的实验室数据很好但真实用户数据很差，说明你的真实用户的设备或网络条件比模拟环境差。需要针对低端设备和慢网络优化。

移动端优化与Mobile-First Indexing

从2023年开始，Google完全切换到Mobile-First Indexing。这意味着Google只看你网站的移动端版本来决定排名。

如果你的移动端版本缺少内容、加载慢、体验差，你的排名就会受影响——即使桌面端版本很完美。

Mobile-First Indexing的要求

  • 内容一致

    ：移动端和桌面端的内容必须一致。不要在移动端隐藏内容

  • 结构化数据一致

    ：移动端和桌面端的Schema标记必须一致

  • Meta标签一致

    ：Title、Description、robots标签在两个版本上必须一致

  • 图片一致

    ：移动端的图片要有Alt文本，格式和质量不能比桌面端差

响应式设计 vs 独立移动站

Google推荐响应式设计（Responsive Design）——一个URL，根据屏幕大小自动调整布局。

不推荐独立移动站（m.example.com）。原因：

  • 需要维护两套内容

  • 需要配置正确的Canonical和Alternate标签

  • 容易出现内容不一致

  • 增加技术复杂度

如果你还在用独立移动站，强烈建议迁移到响应式设计。

移动端技术检查清单

  • viewport meta标签：<meta name="viewport" content="width=device-width, initial-scale=1">

  • 字体大小至少16px（避免用户需要缩放）

  • 触摸目标至少48x48像素，间距至少8px

  • 不使用Flash（已经没人用了，但有些老网站还有）

  • 不使用需要横向滚动的布局

  • 表单输入使用正确的input type（email、tel、number等），触发正确的键盘

 

HTTPS和网站安全

HTTPS是确认的排名因素。Google从2014年就开始把HTTPS作为排名信号。

到2026年，如果你的网站还没有HTTPS，你已经落后了。Chrome会在地址栏显示"不安全"警告，用户信任度直接归零。

SSL/TLS证书

HTTPS需要SSL/TLS证书。获取证书的方式：

  • Let's Encrypt

    ：免费，自动续期，大多数主机都支持一键安装

  • Cloudflare

    ：免费SSL，同时提供CDN和DDoS防护

  • 付费证书

    ：DigiCert、Comodo等，适合需要EV证书的企业

对大多数网站来说，Let's Encrypt的免费证书就够了。

HTTPS迁移检查清单

如果你的网站还在用HTTP，迁移到HTTPS时需要注意：

  1. 安装SSL证书

  2. 设置HTTP到HTTPS的301重定向

  3. 更新所有内链为HTTPS

  4. 更新Canonical标签为HTTPS

  5. 更新Sitemap为HTTPS URL

  6. 检查混合内容（HTTP资源在HTTPS页面上加载）

  7. 更新Google Search Console（添加HTTPS版本的属性）

  8. 更新Google Analytics的默认URL

  9. 更新robots.txt中的Sitemap URL

  10. 通知外链来源更新链接（如果可能）

 

常见的HTTPS问题

混合内容（Mixed Content）：HTTPS页面上加载了HTTP资源（图片、CSS、JS）。浏览器会显示警告或直接阻止加载。

检查混合内容：

  • Chrome DevTools → Console，查看Mixed Content警告

  • 用Why No Padlock工具检查

  • 用Screaming Frog爬取网站，筛选HTTP资源

证书过期：SSL证书有有效期。过期后浏览器会显示安全警告，用户无法访问网站。设置自动续期（Let's Encrypt默认90天，支持自动续期）。

重定向链：HTTP → HTTPS → www → non-www，多次重定向会拖慢速度。应该一步到位：HTTP non-www → HTTPS non-www（或你选择的最终版本）。

结构化数据（Schema Markup）

结构化数据是用标准化的格式告诉Google你的页面内容是什么。它不直接影响排名，但能让你的搜索结果更丰富——显示星级评分、价格、FAQ、面包屑导航等。

根据Google官方文档，结构化数据使用Schema.org词汇表，推荐JSON-LD格式。

JSON-LD格式

JSON-LD是Google推荐的结构化数据格式。它是一段放在<script>标签里的JSON代码：

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "2-Inch Stainless Steel Ball Valve",
  "description": "Full port ball valve, SS316, 1000 WOG",
  "image": "https://example.com/images/ball-valve.jpg",
  "brand": {
    "@type": "Brand",
    "name": "YourBrand"
  },
  "offers": {
    "@type": "Offer",
    "price": "45.99",
    "priceCurrency": "USD",
    "availability": "https://schema.org/InStock"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.8",
    "reviewCount": "127"
  }
}
</script>

 

常用的Schema类型

Schema类型

适用场景

搜索结果效果

Product

产品页

显示价格、库存、评分

Article

博客文章

显示发布日期、作者

FAQ

常见问题页面

显示问答折叠

HowTo

教程页面

显示步骤

BreadcrumbList

所有页面

显示面包屑导航

LocalBusiness

本地商家

显示地址、电话、营业时间

Organization

关于我们页面

显示公司信息、Logo

Review

评论页面

显示星级评分

VideoObject

视频页面

显示视频缩略图

Event

活动页面

显示日期、地点

 

结构化数据的验证

写完结构化数据后，必须验证：

  • Google Rich Results Test：检查是否符合Google的富媒体结果要求

  • Schema.org Validator：检查Schema语法是否正确

常见错误：

  • 必填字段缺失（比如Product Schema缺少price）

  • 数据和页面内容不一致（Schema里的价格和页面显示的价格不同）

  • 使用了Google不支持的Schema类型

  • JSON语法错误（缺少逗号、引号不匹配）

 

不要滥用结构化数据

Google明确警告：结构化数据必须反映页面的真实内容。如果你的页面没有评论，不要添加Review Schema。如果你的产品没有评分，不要伪造AggregateRating。

违反这个规则，Google会对你的网站施加手动处罚（Manual Action），你的富媒体结果会被移除。

爬虫预算优化

爬虫预算（Crawl Budget）是Google分配给你网站的爬取资源。Google不会无限制地爬取你的网站——它需要在有限的资源内爬取整个互联网。

爬虫预算由什么决定

根据Google官方博客，爬虫预算由两个因素决定：

  • 爬取速率限制（Crawl Rate Limit）

    ：Google不想因为爬取太快而拖垮你的服务器。如果你的服务器响应慢，Google会自动降低爬取速度。

  • 爬取需求（Crawl Demand）

    ：Google对你网站内容的兴趣程度。热门页面、经常更新的页面会被更频繁地爬取。

 

什么网站需要关注爬虫预算

小网站（几百个页面）通常不需要担心爬虫预算。Google有足够的资源爬取你的所有页面。

需要关注爬虫预算的网站：

  • 大型电商网站（几万到几百万个产品页）

  • 新闻网站（每天发布大量内容）

  • UGC网站（用户生成内容，页面数量不可控）

  • 有大量参数URL的网站

 

浪费爬虫预算的常见原因

原因

说明

解决方案

参数URL

筛选、排序、分页生成大量URL

robots.txt屏蔽 + Canonical标签

重复内容

同一内容多个URL

Canonical标签 + 301重定向

软404

页面返回200但内容是"未找到"

返回真正的404状态码

重定向链

A→B→C→D多次重定向

直接从A重定向到D

低质量页面

空页面、薄内容页面

noindex或删除

无限爬取陷阱

日历、搜索结果等生成无限URL

robots.txt屏蔽

服务器慢

响应时间长，Google降低爬取速度

优化服务器性能

优化爬虫预算的方法

  1. 清理无用URL

    ：用robots.txt屏蔽不需要爬取的URL模式

  2. 修复重定向链

    ：所有重定向一步到位

  3. 修复软404

    ：让空页面返回真正的404

  4. 优化Sitemap

    ：只包含需要索引的页面

  5. 提升服务器速度

    ：更快的响应 = Google爬得更多

  6. 优化内链

    ：确保重要页面有足够的内链

  7. 使用lastmod

    ：在Sitemap中准确标注最后修改日期

 

监控爬虫行为

在Google Search Console的"设置 → 抓取统计信息"中，可以看到：

  • 每天的爬取请求数

  • 平均响应时间

  • 爬取的文件类型

  • 爬取状态码分布

如果你发现Google大量爬取无用页面（参数URL、旧的重定向），说明你的爬虫预算在被浪费。

日志分析：看清Google的真实行为

Google Search Console告诉你Google索引了什么。但日志分析告诉你Google实际爬取了什么。

这两者可能差别很大。

什么是日志分析

你的服务器会记录每一次访问请求，包括Googlebot的访问。通过分析这些日志，你可以看到：

  • Googlebot爬取了哪些页面

  • 爬取频率是多少

  • 哪些页面从来没被爬取过

  • Googlebot遇到了哪些错误

  • 爬取的响应时间

 

日志分析工具

工具

价格

特点

Screaming Frog Log Analyzer

$149/年

专业的SEO日志分析工具

Botify

企业级定价

大型网站的爬虫分析平台

JetOctopus

$60/月起

云端日志分析，支持大数据量

GoAccess

免费开源

通用日志分析工具，需要手动筛选bot

ELK Stack

免费开源

Elasticsearch + Logstash + Kibana，灵活但需要技术能力

日志分析的关键发现

通过日志分析，你可能发现：

  • 重要页面没被爬取

    ：说明内链不够，或者页面层级太深

  • 垃圾URL被大量爬取

    ：说明爬虫预算在浪费

  • 爬取频率下降

    ：可能是服务器变慢，或者Google对你的网站兴趣降低

  • 大量5xx错误

    ：服务器不稳定，影响爬取

  • Googlebot和其他bot的比例

    ：如果垃圾bot占了大部分流量，需要屏蔽

     

索引管理：控制Google索引什么

不是所有页面都应该被索引。索引了不该索引的页面，会稀释你网站的整体质量。

Noindex标签

在页面的<head>中添加：

<meta name="robots" content="noindex">

或者通过HTTP响应头：

X-Robots-Tag: noindex

应该noindex的页面：

  • 内部搜索结果页

  • 标签页（如果内容和分类页重复）

  • 筛选/排序结果页

  • 感谢页面、确认页面

  • 隐私政策、服务条款（除非你想让它们出现在搜索结果中）

  • 登录/注册页面

  • 购物车、结账页面

  • 测试页面、草稿页面

 

Google Search Console的索引报告

在Google Search Console的"页面"报告中，你可以看到：

  • 已索引的页面数量

  • 未索引的页面数量及原因

  • 被noindex排除的页面

  • 被Canonical排除的页面

  • 爬取异常的页面

定期检查这个报告。如果你发现重要页面没被索引，需要排查原因。

常见的索引问题

问题

原因

解决方案

"已发现 - 尚未编入索引"

Google发现了URL但还没爬取

增加内链、提交Sitemap、提高页面质量

"已抓取 - 尚未编入索引"

Google爬取了但认为不值得索引

提高内容质量、增加外链、改善用户体验

"被 noindex 标记排除"

页面有noindex标签

如果是误加的，移除noindex

"被 robots.txt 屏蔽"

robots.txt禁止爬取

修改robots.txt允许爬取

"重复网页，Google 选择的规范网页与用户指定的不同"

Google不认可你的Canonical

检查内链、外链、Sitemap是否一致

"服务器错误 (5xx)"

服务器返回500错误

修复服务器问题

"重定向错误"

重定向循环或链条太长

修复重定向配置

 

索引API

Google提供了Indexing API，可以主动通知Google你的页面更新了。但这个API目前只支持JobPosting和BroadcastEvent类型的页面。

对于其他类型的页面，可以用Google Search Console的URL检查工具手动请求索引。但每天有配额限制，不适合大量页面。

更实际的做法是：保持Sitemap更新，确保内链结构合理，让Google自然发现和爬取你的新页面。

国际化技术SEO（Hreflang）

如果你的网站面向多个国家或语言，hreflang标签是必须的。

Hreflang的作用

Hreflang告诉Google：这个页面有不同语言/地区的版本，请根据用户的语言和位置显示正确的版本。

没有hreflang会怎样？

  • Google可能把你的英文页面显示给中文用户

  • 不同语言版本互相竞争排名（关键词蚕食）

  • 用户体验差，跳出率高

Hreflang的实现方式

三种方式，选一种就行：

1. HTML标签（推荐小型网站）

<link rel="alternate" hreflang="en" href="https://example.com/product/" />
<link rel="alternate" hreflang="de" href="https://example.com/de/product/" />
<link rel="alternate" hreflang="ja" href="https://example.com/ja/product/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/product/" />

 

2. HTTP响应头（适合非HTML文件，如PDF）

Link: <https://example.com/product/>; rel="alternate"; hreflang="en",
      <https://example.com/de/product/>; rel="alternate"; hreflang="de"

 

3. Sitemap（推荐大型网站）

<url>
  <loc>https://example.com/product/</loc>
  <xhtml:link rel="alternate" hreflang="en" href="https://example.com/product/" />
  <xhtml:link rel="alternate" hreflang="de" href="https://example.com/de/product/" />
</url>

 

Hreflang常见错误

  • 缺少x-default

    ：x-default指定当没有匹配的语言版本时显示哪个页面

  • 不对称

    ：A页面的hreflang指向B，但B没有指回A。必须双向引用

  • 语言代码错误

    ：用"en-uk"而不是"en-gb"，用"zh-cn"而不是"zh-Hans"

  • Canonical和hreflang冲突

    ：每个语言版本的Canonical应该指向自己，不是指向其他语言版本

  • 返回4xx/5xx

    ：hreflang指向的URL必须返回200

 

语言代码参考

语言/地区

Hreflang代码

说明

英语（全球）

en

不指定地区

英语（美国）

en-us

针对美国用户

英语（英国）

en-gb

针对英国用户

德语

de

所有德语用户

德语（奥地利）

de-at

针对奥地利用户

简体中文

zh-Hans

简体中文用户

繁体中文

zh-Hant

繁体中文用户

日语

ja

日语用户

西班牙语

es

所有西班牙语用户

默认

x-default

无匹配时的默认版本

JavaScript SEO

现代网站越来越依赖JavaScript。React、Vue、Angular、Next.js——这些框架让前端开发更高效，但也给SEO带来了挑战。

Google如何处理JavaScript

Google的爬取流程分两步：

  1. 爬取HTML

    ：Googlebot获取页面的原始HTML

  2. 渲染

    ：Google的Web Rendering Service（WRS）执行JavaScript，生成最终的DOM

问题在于：这两步之间可能有延迟。Google需要额外的资源来渲染JavaScript，所以渲染队列可能会积压。你的页面可能被爬取了，但要等几天甚至几周才被渲染和索引。

三种渲染方式

渲染方式

说明

SEO友好度

适用场景

服务端渲染（SSR）

服务器生成完整HTML

最好

内容型网站、电商

静态生成（SSG）

构建时生成HTML文件

最好

博客、文档、营销页

客户端渲染（CSR）

浏览器执行JS生成内容

最差

后台管理、不需要SEO的应用

混合渲染

关键内容SSR，非关键内容CSR

好

大型应用

如果你的网站需要SEO流量，强烈推荐SSR或SSG。

常见的JavaScript SEO问题

  • 内容在HTML源码中不存在

    ：如果你查看页面源码（Ctrl+U），看不到主要内容，说明内容是JS渲染的。Google可能无法正确索引。

  • 内链是JS事件而不是<a>标签

    ：onclick="window.location='...'"这种写法，Googlebot可能无法识别为链接。必须用标准的<a href="...">标签。

  • 懒加载内容

    ：如果内容需要滚动或点击才加载，Googlebot可能看不到。关键内容不要懒加载。

  • JS错误阻止渲染

    ：如果JS报错，页面可能无法正确渲染。定期检查JS错误。

  • Meta标签通过JS动态设置

    ：Title和Description最好在服务端生成，不要依赖JS动态设置。

 

JavaScript SEO检查方法

  1. Google Search Console的URL检查工具

    ：查看Google渲染后的页面截图，确认内容是否完整

  2. 查看页面源码

    ：Ctrl+U查看原始HTML，确认关键内容是否在源码中

  3. 禁用JavaScript测试

    ：在Chrome DevTools中禁用JS，看页面是否还有内容

  4. site:搜索

    ：在Google中搜索site:example.com，看索引的页面是否有正确的标题和描述

Next.js和Nuxt.js

如果你用React或Vue，推荐使用Next.js（React）或Nuxt.js（Vue）。这两个框架原生支持SSR和SSG，大大简化了JavaScript SEO。

Next.js的SEO优势：

  • 支持SSR、SSG、ISR（增量静态再生成）

  • 自动代码分割，减少JS体积

  • 内置图片优化（next/image）

  • 内置Head组件，方便设置Meta标签

  • 支持Sitemap生成

 

网站迁移的技术SEO

网站迁移是技术SEO中风险最高的操作。换域名、换平台、改URL结构——任何一个环节出错，都可能导致流量暴跌。

网站迁移的类型

  • 域名迁移

    ：从old-domain.com迁移到new-domain.com

  • 平台迁移

    ：从WordPress迁移到Shopify，或反过来

  • URL结构变更

    ：从/products/category/product-name 改为 /product-name

  • 协议迁移

    ：从HTTP迁移到HTTPS

  • 子域名迁移

    ：从blog.example.com迁移到example.com/blog

 

网站迁移检查清单

迁移前：

  1. 用Screaming Frog爬取旧网站，记录所有URL

  2. 导出所有页面的排名和流量数据（Google Search Console + Analytics）

  3. 记录所有外链指向的URL（Ahrefs或SEMrush）

  4. 创建完整的URL映射表（旧URL → 新URL）

  5. 在测试环境验证所有重定向

迁移中：

  1. 设置所有301重定向

  2. 更新所有内链

  3. 更新Canonical标签

  4. 更新Sitemap

  5. 更新robots.txt

  6. 更新结构化数据中的URL

迁移后：

  1. 在Google Search Console中添加新域名/URL

  2. 提交新的Sitemap

  3. 如果是域名迁移，使用Google Search Console的"地址更改"工具

  4. 监控流量变化（预期会有短期下降）

  5. 检查404错误

  6. 验证所有重定向正常工作

  7. 监控排名变化

 

迁移后的流量恢复

根据Search Engine Journal的数据，一次成功的网站迁移通常需要3-6个月才能完全恢复流量。如果迁移做得好，流量可能在几周内就恢复大部分。

如果迁移后流量持续下降超过3个月，需要排查：

  • 是否有重要页面没有设置重定向

  • 重定向是否是301（不是302）

  • 新页面的内容质量是否下降

  • 是否有技术问题（noindex、robots.txt屏蔽等）

     

技术SEO审计：系统化检查

技术SEO不是一次性的工作。网站在不断变化——新页面、新功能、插件更新、服务器变更——每一次变化都可能引入新的技术问题。

建议每季度做一次完整的技术SEO审计。

审计工具

工具

价格

特点

Screaming Frog

免费（500 URL）/ $259/年

最全面的爬虫工具，桌面端

Ahrefs Site Audit

$99/月起（含其他功能）

云端审计，自动定期扫描

SEMrush Site Audit

$129/月起（含其他功能）

云端审计，问题分类清晰

Sitebulb

$152/年

可视化强，适合报告

Google Search Console

免费

Google官方数据，必用

Lighthouse

免费

Chrome内置，性能+可访问性+SEO

技术SEO审计清单

爬取和索引：

  • robots.txt是否正确配置

  • Sitemap是否包含所有重要页面

  • 是否有重要页面被noindex

  • 是否有大量404错误

  • 是否有重定向链或循环

  • 索引页面数是否和预期一致

页面级别：

  • 每个页面是否有唯一的Title和Description

  • Title长度是否在50-60字符之间

  • 是否有重复的Title或Description

  • H1标签是否存在且唯一

  • 图片是否有Alt文本

  • Canonical标签是否正确

性能：

  • Core Web Vitals是否达标

  • TTFB是否在200ms以内

  • 页面大小是否合理（建议3MB以内）

  • 图片是否压缩和使用现代格式

  • CSS/JS是否压缩和合并

安全和协议：

  • 是否全站HTTPS

  • 是否有混合内容

  • SSL证书是否有效

  • HTTP到HTTPS重定向是否正确

结构化数据：

  • Schema标记是否正确

  • 是否有验证错误

  • 是否覆盖了所有适用的页面类型

移动端：

  • 是否响应式设计

  • 移动端内容是否和桌面端一致

  • 触摸目标是否足够大

  • 是否有移动端特有的问题

     

实战案例：Shopify网站的技术SEO审计

我们用一个真实的Shopify外贸独立站案例来演示技术SEO审计的过程。

背景

一个卖工业配件的Shopify网站，上线6个月，每月自然搜索流量约2000。产品页约500个，博客文章约30篇。老板觉得流量增长太慢，请我们做技术SEO审计。

发现的问题

问题1：大量重复的Title Tag

用Screaming Frog爬取后发现，200多个产品页的Title Tag格式是"产品名 | 品牌名"，但很多产品名几乎一样——只是尺寸不同。

比如：

  • "Ball Valve 1/2 Inch | BrandName"

  • "Ball Valve 3/4 Inch | BrandName"

  • "Ball Valve 1 Inch | BrandName"

Google看到这些几乎一样的Title，不知道该排哪个。

解决：重写Title Tag，加入更多差异化信息——材质、压力等级、应用场景。

问题2：集合页没有内容

所有集合页（分类页）只有产品列表，没有任何文字内容。Google看到的就是一堆产品链接。

解决：给每个集合页添加200-500字的分类描述，包含目标关键词。

问题3：图片没有Alt文本

500个产品页，超过2000张图片，其中80%没有Alt文本。

解决：用Shopify的批量编辑功能，或者用Smart SEO应用自动生成Alt文本。

问题4：页面速度差

移动端LCP 4.8秒，CLS 0.32。主要原因：

  • 产品图片没有压缩（平均每张2MB）

  • 安装了12个Shopify应用，每个都注入JS

  • 使用了一个臃肿的第三方主题

解决：压缩图片到200KB以内、卸载不必要的应用（从12个减到5个）、切换到更轻量的主题。

问题5：没有Schema标记

产品页没有Product Schema，搜索结果里不显示价格和评分。

解决：安装JSON-LD for SEO应用，自动为产品页添加Product Schema。

审计结果

修复这些问题后的3个月：

  • 自然搜索流量从2000增长到5500（+175%）

  • 移动端LCP从4.8秒降到2.1秒

  • CLS从0.32降到0.05

  • 索引页面数从320增加到480（之前很多页面因为质量太低没被索引）

  • 搜索结果中开始显示产品价格和评分（Schema生效）

这个案例说明：技术SEO的基础工作做好，效果是立竿见影的。

WordPress技术SEO配置

WordPress是全球使用最广泛的CMS，占据了超过40%的网站市场份额。它的SEO灵活性很强，但需要正确配置。

必装插件

SEO插件（二选一）：

  • Rank Math：功能更全，免费版就很强大。推荐。

  • Yoast SEO：老牌插件，稳定可靠，但免费版功能有限。

缓存插件（选一个）：

  • WP Rocket：付费，但配置最简单，效果最好

  • LiteSpeed Cache：免费，如果你的服务器是LiteSpeed

  • W3 Total Cache：免费，功能强大但配置复杂

图片优化：

  • ShortPixel：自动压缩上传的图片，支持WebP转换

  • Imagify：WP Rocket同一家公司出品，集成度好

 

WordPress技术SEO设置

1. 固定链接

Settings → Permalinks → 选择"Post name"（/%postname%/）。这是最干净的URL结构。

2. Rank Math基础设置

  • 启用Sitemap模块

  • 设置全局Title和Description模板

  • 启用面包屑导航

  • 配置Schema默认类型（文章用Article，产品用Product）

  • 在Sitemap设置中排除不需要索引的内容类型（标签、作者归档等）

3. 禁用不需要的功能

  • 禁用WordPress自带的Emoji脚本（减少一个HTTP请求）

  • 禁用XML-RPC（安全考虑）

  • 禁用oEmbed（如果不需要）

  • 限制文章修订版本数量（减少数据库膨胀）

在wp-config.php中添加：

define('WP_POST_REVISIONS', 5);
define('DISALLOW_FILE_EDIT', true);

4. 数据库优化

WordPress数据库会随着时间膨胀——文章修订、垃圾评论、过期的transients。定期清理：

  • 用WP-Optimize插件自动清理

  • 或者手动执行SQL清理（需要备份）

 

Cloudflare与CDN配置

CDN（Content Delivery Network）把你的网站内容分发到全球各地的服务器上。用户访问时，从最近的服务器获取内容，速度更快。

对外贸网站来说，CDN几乎是必须的。你的服务器可能在美国，但客户在欧洲、东南亚、中东——没有CDN，这些地区的用户访问速度会很慢。

Cloudflare免费版就够用

Cloudflare的免费版提供：

  • 全球CDN

  • 免费SSL证书

  • 基础DDoS防护

  • DNS管理

  • 页面规则（3条免费）

 

Cloudflare SEO相关设置

设置

推荐值

原因

SSL/TLS模式

Full (Strict)

确保端到端加密

Always Use HTTPS

开启

自动重定向HTTP到HTTPS

Auto Minify

开启（HTML/CSS/JS）

减小文件大小

Brotli压缩

开启

比Gzip压缩率更高

Browser Cache TTL

1个月

减少重复请求

Rocket Loader

测试后决定

可能加速JS加载，但也可能导致问题

Early Hints

开启

提前告诉浏览器需要加载的资源

注意：Cloudflare的Rocket Loader可能会和某些JS冲突。开启后一定要测试网站功能是否正常。

技术SEO与AI搜索

2026年，AI搜索已经不是未来——它是现在。Google的AI Overviews、Bing的Copilot、Perplexity、ChatGPT的搜索功能——这些AI搜索引擎正在改变用户获取信息的方式。

技术SEO对AI搜索同样重要。AI搜索引擎仍然需要爬取和理解你的网页内容。

AI搜索对技术SEO的新要求

  • 结构化数据更重要

    ：AI需要结构化的信息来生成回答。Schema标记帮助AI理解你的内容

  • 内容的可提取性

    ：AI需要能够提取你页面的关键信息。清晰的HTML结构（H1-H6、列表、表格）比一大段纯文本更容易被AI理解

  • E-E-A-T信号

    ：AI搜索引擎倾向于引用权威来源。作者信息、引用来源、专业资质——这些信号帮助AI判断你的内容是否可信

  • 页面速度仍然重要

    ：AI爬虫也有爬取预算。慢的网站会被爬取得更少

LLMs.txt

LLMs.txt是一个新兴的标准，类似于robots.txt，但专门针对AI爬虫。它告诉AI模型如何使用你的内容。

目前这个标准还在早期阶段，没有证据表明它能提升AI搜索可见性。但如果你想尝试，可以在网站根目录创建一个llms.txt文件。

总结

技术SEO是SEO的地基。地基不牢，上面的内容和外链都是空中楼阁。

核心要点：

  1. 确保可爬取

    ：robots.txt正确配置，Sitemap完整，内链结构合理

  2. 确保可索引

    ：Canonical标签正确，noindex只用在该用的地方，定期检查索引状态

  3. 确保速度快

    ：Core Web Vitals达标，图片优化，CDN加速

  4. 确保移动友好

    ：响应式设计，内容一致，触摸友好

  5. 确保安全

    ：全站HTTPS，无混合内容

  6. 确保结构清晰

    ：Schema标记，清晰的URL，扁平的架构

  7. 定期审计

    ：每季度一次完整审计，及时发现和修复问题

技术SEO不需要你成为程序员。但你需要理解这些概念，知道怎么检查，知道出了问题找谁修。

如果你是用WordPress或Shopify，大部分技术SEO问题都有现成的插件或应用可以解决。关键是：知道要检查什么，定期检查，发现问题及时修复。

技术SEO做好了，你的内容和外链才能发挥最大价值。