🏗️ 第 02

建站层

技术地基，把站搭对（0 → 1）

📖 14 分钟阅读 🕑 更新于 2026-06-22

站点搭建与技术 SEO 这一层只解决一个问题：让搜索引擎顺畅地发现、抓取、理解并索引你的页面。它位于关键词研究之后、内容生产之前。无论你的研究多精准、文章写得多好，只要爬虫读不到你的页面、URL 一团乱，或者页面加载三秒还是一片空白，排名就无从谈起。

好消息是：这是写代码的人优势最大的一层。剥掉那些行话，绝大多数「技术 SEO 问题」无非是配置文件、HTTP 头、HTML 标签和性能优化——都是你每天都在做的事。把爬虫想成一个有点没耐心的 HTTP 客户端：它对 JavaScript 没什么耐心，还有严格的时间预算。你的任务就是给它端上干净、快速、标注清晰的 HTML。本页会逐一拆解每个环节，附上可直接复制粘贴的代码。

域名与主机

在任何一字节内容产生意义之前，请求得先能解析、连接，并快速响应。这就是域名和主机要解决的事。

域名选择。 挑一个简短、好记、与主题相符的名字。几条实用规则：

  • 全新域名拿不到「年龄」加成，但也不背负有毒外链历史——一张白纸完全没问题。
  • 别用塞满连字符的完全匹配关键词域名（best-cheap-seo-tools-2026.com），它们看着就像垃圾站，排名只会更差而不是更好。
  • 选定一个规范主机名并坚持到底。在 www 和非 www 之间一次性做出决定，然后把另一个永久重定向过去。

HTTPS 没有商量余地。 它是一个已确认的（虽然权重较轻的）排名信号，而且现代浏览器会把纯 HTTP 标注为「不安全」。用 301 重定向加 HSTS 头在全站强制启用，让浏览器从此连尝试 HTTP 都不会：

# nginx: redirect all HTTP to HTTPS, then enforce HSTS
server {
  listen 80;
  server_name example.com www.example.com;
  return 301 https://example.com$request_uri;
}
server {
  listen 443 ssl;
  server_name www.example.com;
  return 301 https://example.com$request_uri;   # consolidate www -> apex
}
server {
  listen 443 ssl;
  server_name example.com;
  add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload";
  # ... your site ...
}

上面的写法把四个地址——http://、https://、带 www、不带 www——收敛成单一的规范源。如果你跳过这一步，搜索引擎可能会把它们当成多达四个独立站点，分散同一份权重。

TTFB 与服务器响应时间。 Time To First Byte 是服务器在收到请求后发出第一个字节所需的时间。Google 把响应慢当成一个抓取效率问题：服务器迟钝意味着每次来访能抓取的页面更少。对缓存/静态响应，目标是 TTFB 低于约 200ms；对动态响应，低于约 600ms。

CDN。 内容分发网络会把你的页面缓存到物理上离用户更近的服务器上，为全球受众大幅削减延迟，并吸收流量峰值。对静态站点来说，这几乎是免费的、几乎像魔法——HTML、CSS 和图片是从离访客几百公里的边缘节点送出的，而不是隔着一整个大陆。

🧑‍💻 开发者视角：用 curl 检查线上响应。确认返回 200、strict-transport-security 头存在，且没有意外冒出来的 x-robots-tag: noindex：

curl -sI https://example.com | grep -iE 'http/|strict-transport|x-robots'

站点架构

架构指的是你的 URL 和链接如何组织。做对了，权重就能顺畅流动、爬虫也能触达每个角落；做错了，重要页面就会孤零零地埋在三层子目录深处，没有任何链接指向它们。

干净、语义化的 URL。 一个 URL 应当读起来像面包屑导航。对比一下：

Good:  example.com/seo/technical/canonical-tags
Bad:   example.com/index.php?p=482&cat=7&ref=nav

经验法则：全小写，词与词之间用连字符（不要用下划线或空格），不带文件扩展名，规范路径里不出现 session ID 或追踪垃圾参数，用人会真正去敲的词。URL 是给人看的，也是给爬虫看的，更是给那些在 SERP 里决定是否点击你链接的人看的——保持它有描述性。想看 URL 在结果里如何呈现？用本站的 SERP 预览工具。

扁平的层级。 让每个重要页面都能在距离首页约三次点击以内触达。树越浅，「链接权重」能流到深层页面就越多，爬虫也越容易找到它们。一个需要点七次才能到达的页面，恰恰正确地传递了一个信号：你自己并不重视它。

内部链接与主题集群模型。 内部链接干两件事：为爬虫规划穿越全站的路线，以及在页面之间传递权重。最有效的结构是主题集群：

  • 一个**支柱页（pillar page）**宽泛地覆盖一个大主题（/seo/technical-seo）。
  • 若干**集群页（cluster pages）**各自深挖一个子要点（/seo/technical-seo/robots-txt、/seo/technical-seo/sitemaps）。
  • 每个集群页向上链接到支柱页；支柱页向下链接到每个集群页。

这告诉搜索引擎「这个站点在技术 SEO 上是权威」，而不只是「这个站点有一篇讲 robots.txt 的文章」。始终使用有描述性的锚文本（robots.txt configuration），而不是 click here——锚文本是被链接页面的一个排名信号。

💡 提示：把你的站点想象成一棵树。首页是根，分类是枝，文章是叶。爬虫沿着内部链接爬上这棵树——一个没有任何入站内链的孤儿页面，就是一片悬在半空的叶子，可能永远不会被抓取。

技术 SEO

这是本层的核心，也是你的主场。下面的一切都是一个文件、一个标签或一个 HTTP 头。

robots.txt

放在站点根目录（example.com/robots.txt）的纯文本文件，告诉爬虫哪些路径可以请求。关键点：它控制的是抓取，而非索引。被 robots.txt 屏蔽的页面，如果其他站点链接到它，仍可能出现在结果里（以一条没有摘要的裸 URL 形式）。要把某个东西挡在索引之外，你需要 noindex——见下文。

User-agent: *
Allow: /
Disallow: /admin/
Disallow: /cart/
Disallow: /*?sort=          # block faceted/sort parameter URLs

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

⚠️ 注意：千万不要对一个你又想用 noindex 去索引的页面执行 Disallow。如果爬虫抓不到这个页面，它就永远看不到 noindex 标签，于是页面会卡在索引里出不来。要么屏蔽抓取，要么允许抓取 + noindex——不能两者都做。

sitemap.xml

一份你希望被索引的 URL 的 XML 清单。它不保证索引，但这是你把一份干净的清单递给 Google 的方式——对大型站点或内链很少的页面尤其宝贵。只收录规范的、可索引的、状态码为 200 的页面（不含重定向、不含 noindex、不含重复页）。

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.com/seo/technical-seo</loc>
    <lastmod>2026-06-22</lastmod>
  </url>
  <url>
    <loc>https://example.com/seo/technical-seo/robots-txt</loc>
    <lastmod>2026-06-20</lastmod>
  </url>
</urlset>

在 Google Search Console 里提交它（Sitemaps 部分），并在 robots.txt 里引用它。别手动维护这个文件——用本站的 robots.txt 与 sitemap 生成器把两个文件一起生成出来。

canonical（规范标签）

当同一份内容能通过多个 URL 触达时（追踪参数、末尾斜杠、HTTP 与 HTTPS、打印版），canonical 标签会指明那个「真身」，让权重合并而不是被拆散。把它放进 <head>，并在首选页面上做成自引用：

<!-- on https://example.com/shoes?color=red -->
<link rel="canonical" href="https://example.com/shoes" />

使用绝对 URL，每个页面只放一个 canonical，并确保 canonical 指向的 URL 自身返回 200（不是重定向、也不是 noindex）。canonical 是一个强烈的提示，而非命令——保持各项信号一致，比如别把 canonical 指向一个你又在 robots.txt 里屏蔽掉的页面。

hreflang（多语言）

如果你以多种语言或面向多个地区提供同一份内容，hreflang 会告诉 Google 该给哪类用户展示哪个版本。绊倒所有人的那条规则是：引用必须双向且完整——集合里的每个页面都必须列出每个版本，包括它自己。再加一个 x-default 作为兜底。

<!-- in <head> of every page in the language set -->
<link rel="alternate" hreflang="en"    href="https://example.com/en/build" />
<link rel="alternate" hreflang="zh-CN" href="https://example.com/zh/build" />
<link rel="alternate" hreflang="x-default" href="https://example.com/en/build" />

如果英文页面指向了中文页面，而中文页面没有指回来，Google 会忽略整个集群。使用 ISO 语言代码（en、zh-CN），并且绝不要对备选版本用 robots.txt 或 noindex——它们全都需要可抓取。

Schema 结构化数据

结构化数据是一种机器可读的元数据，用来描述一个页面是什么——一篇文章、一份食谱、一件商品、一组 FAQ。Google 用它来驱动富结果（星级评分、FAQ 折叠面板、SERP 里的面包屑），即便你的排名没变，这些也能提升点击率。在 <script> 标签里使用 JSON-LD——这是 Google 推荐的格式，能让标记与内容彼此分离：

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "A Developer's Guide to Technical SEO",
  "author": { "@type": "Person", "name": "Jane Dev" },
  "datePublished": "2026-06-22",
  "dateModified": "2026-06-22",
  "image": "https://example.com/img/technical-seo.png"
}
</script>

只标记页面上确实可见的内容（造假有招致人工处罚的风险），然后用 Google 的 Rich Results Test 校验。用本站的 Schema 生成器为 Article、Breadcrumb、FAQ 和 Organization 生成合法的 JSON-LD。

移动优先索引

Google 使用你页面的移动版本来索引和排名，而不是桌面版本。实际后果是：别把内容、标题或结构化数据藏在「仅桌面」的路径后面；确保移动版页面拥有相同的正文文本、相同的 hreflang/canonical 标签，以及相同的 Schema。响应式布局（一份 HTML 负载，由 CSS 驱动断点）是最稳妥的方案，因为只有一个版本需要保持同步。

Core Web Vitals

三项量化真实用户体验、并直接进入排名考量的指标。下面的目标值是「良好」阈值：

指标衡量什么良好常见修复
LCP（Largest Contentful Paint）最大元素渲染完成所需的时间≤ 2.5s优化主图、预加载它、加快 TTFB
INP（Interaction to Next Paint）对用户输入的响应速度≤ 200ms拆分长 JS 任务、少发 JavaScript
CLS（Cumulative Layout Shift）视觉稳定性（不乱跳）≤ 0.1给图片设 width/height、为广告/嵌入预留空间

提升 CLS 最立竿见影的一招，就是给媒体标注尺寸，让浏览器在加载前就预留好空间：

<!-- browser reserves the box immediately; nothing jumps when the image arrives -->
<img src="/hero.webp" width="1200" height="630" alt="Technical SEO diagram" />

用 Lighthouse（实验室数据）和 Search Console 里的 Core Web Vitals 报告（来自真实用户的现场数据）来测量——优化时以现场数据为准，因为那才是 Google 真正采用的。

抓取预算、索引管理与重复内容

**抓取预算（crawl budget）**是 Google 在给定时间窗口内会从你站点抓取的 URL 上限数量。小站点很少触顶；大型站点（5 万以上 URL、大型电商的多维筛选）则绝对会撞墙。当爬虫把预算花在垃圾上时，你就在浪费它：无穷无尽的参数组合、翻页死胡同、重定向链、软 404。

重复内容会稀释这份预算，并扰乱排名。工具箱：

  • 用 canonical 合并近似重复（被筛选/排序过的商品列表）。

  • 对那些必须保持公开、但你不想让其参与排名的薄页（站内搜索结果、标签归档），用 noindex：

    <meta name="robots" content="noindex, follow" />

    或者对非 HTML 文件使用等价的 HTTP 头：

    X-Robots-Tag: noindex

  • 用 robots.txt 阻止爬虫在整块没有 SEO 价值的区域上浪费预算（/cart/、多维筛选参数 URL）。

  • 把重定向链（A → B → C）修成单跳（A → C）；每一跳都消耗预算，还会漏掉一点权重。

🧑‍💻 开发者视角：用「每个 URL 都是爬虫要付费的一次请求」来思考。上线前，用 Screaming Frog 之类的工具抓取你自己的站点，审计这份清单——你通常会发现几百个参数 URL、日历页面或翻页归档正在悄悄吃掉预算。

选择技术栈

你选用的框架或 CMS，决定了有多少 SEO 工作是被替你处理好的、又有多少要你亲手接线。决定性因素是 HTML 如何送到爬虫手里：服务端渲染/静态 HTML（很棒）对比客户端渲染——后者的首次响应是一个空的 <div id="root"> 外壳，只有等 JavaScript 跑完才填充（有风险——爬虫可能渲染得很晚或者渲染不全）。

技术栈渲染方式SEO 友好度备注
WordPress服务端渲染高，需插件Yoast / Rank Math 处理 meta、sitemap、Schema。性能依赖缓存插件。
Webflow服务端渲染/静态开箱即高可视化搭建器，内置 title/canonical/hreflang 字段。自定义逻辑有限。
Next.jsSSR 或 SSG（或 CSR）配置得当则高完全可控，但需你自己通过 generateMetadata 和动态 sitemap 路由接好 SEO。默认的 CSR 不友好。
Astro默认静态（SSG）非常高默认零 JS → HTML 飞快、天然占 Core Web Vitals 上风。适合内容/文档/博客。本站就跑在 Astro 上。

⚠️ 注意：纯客户端渲染的单页应用在首次加载时送出的是一个空白 HTML 外壳。Google 能渲染 JavaScript，但更慢、更不可靠，而其他爬虫（部分社交和 AI 机器人）根本不渲染。如果 SEO 重要，就选 SSG 或 SSR，让第一个字节里就已经包含你的内容。

对于一个从零搭建内容导向 SEO 站点的开发者，静态优先的生成器（Astro，或处于 SSG 模式的 Next.js）会给你最好的默认值：快速的 TTFB、首次响应里就有干净的 HTML，以及对上文涵盖的每个标签都易于掌控。

小结

这一层的心法是：给爬虫端上干净、快速、标注清晰的 HTML，永远别让它去猜。 每一个「技术 SEO 问题」都可归结为一个文件、一个标签、一个 HTTP 头或一毫秒——而这恰好正是你早已知道怎么解决的那类问题。别手写那些琐碎的文件；用本站的 robots/sitemap 和 Schema 工具生成它们，然后逐项验证。

✅ 检查清单

  • 全站强制 HTTPS，加上 HSTS，并把每个域名变体（http、www）301 到唯一的规范源
  • 生成并提交 robots.txt 与 sitemap.xml，只收录规范的、状态码 200 的页面
  • 为每个重要页面加上自引用的 canonical 标签，并解决重复/参数 URL
  • 如果你提供多种语言，设置完整、双向的 hreflang 标签（外加 x-default）
  • 为 Article、Breadcrumb 和 Organization 添加 JSON-LD 结构化数据，然后通过 Rich Results Test
  • 运行 Lighthouse 并确认 LCP ≤ 2.5s、INP ≤ 200ms、CLS ≤ 0.1——对照 Search Console 里的现场数据进行验证
  • 审计你的 URL 清单（例如用 Screaming Frog），排查孤儿页面、重定向链，以及浪费预算的参数 URL