从 0 开始理解 SEO：我在 Astro 博客中做了什么
从一个前端工程师的视角，记录我在 Astro 个人技术博客中对页面语义、Canonical、Sitemap、robots.txt、渲染架构、Core Web Vitals、Search Console、Open Graph 与内部链接的实践和理解。
过去很长一段时间里，我开发的主要都是后台管理系统。
这类系统通常有几个共同特点：
- 需要登录才能访问
- 页面主要服务企业内部用户
- 搜索引擎没有索引这些页面的必要
- SEO 很少成为前端架构设计的重要因素
因此，虽然已经做了很多年前端开发，我对 SEO 的理解其实一直比较有限。
直到开始搭建自己的个人技术博客，我才第一次真正面对一个问题：
如果我写了一篇技术文章，搜索引擎究竟是怎么发现它、获取它、理解它，并最终把它展示给用户的？
于是我没有单独去背一套 SEO Checklist，而是把这个博客本身当成实验项目：
开发博客
↓
遇到真实 SEO 问题
↓
理解它解决什么问题
↓
实现
↓
验证
↓
再修正自己的理解现在博客已经具备正常持续迭代的基础能力，我也终于可以把一路零散积累的知识重新整理成一套比较完整的 SEO 心智模型。
这篇文章仍然不是“排名技巧大全”。
它更像是一名前端工程师从页面架构出发，对内容网站 SEO 的一次工程化总结。
1. 先建立一个 SEO 生命周期模型
刚开始接触 SEO 时，我很容易把它简化成：
<title>
+
<meta name="description">
+
keywords但真正把博客做下来以后，我发现这些只是页面提供给搜索引擎的一部分信息。
对于一个内容网站，我现在更愿意从一条完整链路理解 SEO：
页面被发现
↓
Discovery
搜索引擎访问 URL
↓
Crawling
获取并处理页面内容
↓
Rendering
决定内容是否进入索引
↓
Indexing
理解页面主题、URL 和页面之间的关系
↓
Understanding
根据用户搜索请求决定是否展示
↓
Search Results
上线后继续观察真实抓取与索引状态
↓
Feedback这条链路也帮我区分了以前经常混在一起的几个问题：
能被发现
≠
一定被抓取
被抓取
≠
一定被索引
被索引
≠
一定获得排名
出现在搜索结果
≠
用户一定愿意点击所以 SEO 并不是给 HTML 补几个特殊标签。
它会从：
Content Model
URL
HTML
Rendering
Internal Links
Performance
Metadata一直延伸到网站上线后的 Search Console 验证。
2. 页面语义：先让每个页面说清楚自己是谁
SEO 最基础的一层，不是“关键词优化”，而是：
一个页面有没有清楚、稳定地表达自己的主题和身份？
在这个博客里，这部分主要由 Content Collection、Title、Description、H1 和 Semantic HTML 一起完成。
2.1 Content Collection 不只是文章数据
我的博客使用 Astro Content Collections 管理内容：
---
title: 从 0 开始理解 SEO
description: ...
publishedAt: 2026-08-11
tags:
- SEO
- Astro
---一开始我只是把这些字段理解成：
文章数据但随着 SEO 能力逐渐增加，我开始发现：
Content Model
↓
页面正文
+
页面 Metadata
+
搜索展示信息
+
社交分享信息例如：
post.data.title
↓
<h1>
<title>
og:title而：
post.data.description
↓
文章简介
meta description
og:description所以，一个设计良好的 Content Model，本身就是 SEO 架构的一部分。
如果内容模型没有稳定的：
title
description
publishedAt后面所有 SEO 能力都会开始到处临时拼数据。
2.2 <title>：文档最重要的标题信号之一
后台系统里，一个应用可能长期共用：
<title>采购管理平台</title>但博客显然不能这样做。
如果三篇文章分别是：
为什么我开始使用 Astro 搭建个人博客
pnpm 的依赖管理机制
Vue 微前端架构实践最终 <title> 却全部是：
Zhou Blog那页面就没有准确表达自己的主题。
因此我的页面会把自己的内容语义交给 Layout：
<BaseLayout title={post.data.title} description={post.data.description} />最终形成：
<title>从 0 开始理解 SEO | Zhou</title>我现在会把职责理解成：
BaseLayout
→ 定义 Metadata 结构
具体 Page / Content
→ 提供页面自己的语义而不是让 Layout 把所有页面内容写死。
2.3 <title> 不等于搜索结果一定展示的标题
这是我很早纠正的一个误区。
页面里写：
<title>Astro 博客开发实践</title>并不意味着搜索结果一定逐字显示：
Astro 博客开发实践搜索系统还可能综合：
- 页面主要视觉标题
<h1>- 页面正文
- Open Graph title
- 页面中的链接文字
- 其他页面指向当前页面的链接文字
所以我现在更愿意把 <title> 理解成：
网站主动提供的一个非常重要的页面标题信号。
而不是“搜索结果标题的强制指令”。
这也意味着 Title 最重要的原则仍然是：
准确描述页面
+
每个重要页面保持独立
+
不要为了 SEO 堆关键词品牌名可以保留，但保持克制：
文章标题 | Zhou2.4 <title> 和 <h1> 不是同一个概念
<title> 位于：
<head>描述整个 HTML 文档。
而 <h1> 是用户在页面正文里真正看到的主标题。
例如：
<title>从 0 开始理解 SEO：我的 Astro 博客实践 | Zhou</title>正文可以是：
<h1>从 0 开始理解 SEO：我在 Astro 博客中做了什么</h1>两者可以高度相关，但不要求逐字一致。
真正需要避免的是明显的语义冲突：
<title>
Astro SEO 实践
<h1>
我的学习日记一个页面应该尽可能稳定地告诉用户和搜索系统：
我到底在讨论什么？
2.5 Meta Description：搜索摘要的候选信息
博客中的文章也会生成：
<meta name="description" content="从一个前端工程师的视角，通过 Astro 个人博客实践逐步理解 SEO。" />我最初会把它理解成：
这就是搜索结果标题下面那段摘要。
但更准确的理解是：
页面实际内容
+
Meta Description
+
用户当前搜索请求
↓
搜索系统决定 Snippet所以 Meta Description 不是：
强制指定搜索结果摘要而更像：
页面主动提供的一份高质量摘要候选这也是为什么它仍然值得认真写。
不要写成：
Astro, SEO, Frontend, JavaScript, Blog而应该真正概括页面：
通过 Astro 个人博客的实际开发过程，
理解 Title、Canonical、Sitemap、渲染架构、
Search Console 与内部链接等 SEO 实践。Title 和 Description 都应该来源于页面自己的内容语义，而不是为了让“SEO 检测工具通过”机械补字段。
2.6 Semantic HTML：让 HTML 自己表达内容结构
博客中我会优先使用：
<header>
<nav>
<main>
<article>
<section>
<footer>
<h1>
<h2>
<p>
<a> <time></time></a>
</p>
</h2>
</h1>
</footer>
</section>
</article>
</main>
</nav>
</header>而不是让所有东西都退化成：
<div></div>语义化 HTML 首先是正确的 Web 开发实践，同时也能够更清楚地表达：
这是文章
这是主要标题
这是导航
这是正文
这是发布时间
这是链接例如：
<article>
<header>
<h1>从 0 开始理解 SEO</h1>
<time datetime="2026-08-11">2026 年 8 月 11 日</time>
</header>
...
</article>相比一堆没有含义的 <div>，它本身就携带更多结构信息。
2.7 lang="zh-CN"：重要，但不是排名技巧
根 HTML 使用：
<html lang="zh-CN"></html>它能够帮助：
浏览器
辅助技术
翻译工具
其他用户代理理解页面主要语言。
但我不会把它理解成：
加了
lang="zh-CN"，Google 才知道这是中文页面。
页面语言仍然主要来自真实内容。
因此目前我首先把 lang 看成：
HTML 文档语义而不是某种特殊 SEO 技巧。
如果未来真的开始维护中文和英文两个版本，才需要进一步研究：
hreflang
国际化 URL
多语言 canonical目前不提前实现。
3. URL 身份、抓取与索引控制
页面内容说清楚以后，下一个问题是：
这份内容到底对应哪个 URL？搜索引擎应该怎样发现和处理它？
这里最容易混淆的是 Canonical、Sitemap、robots.txt 和 noindex。
3.1 Canonical：哪一个 URL 代表这份内容？
例如一篇文章可能通过：
https://example.com/blog/astro访问，也可能带上参数：
https://example.com/blog/astro?utm_source=twitter从用户角度看：
这是同一篇文章但对于搜索系统：
这是不同 URL于是就需要说明：
哪个 URL 最适合作为这份内容的标准版本？
这就是 Canonical URL。
<link rel="canonical" href="https://example.com/blog/astro" />3.2 Canonical 是强信号，不是强制命令
Canonical 更准确的语义是：
如果存在重复或近似内容，我希望这个 URL 作为主要版本。
但搜索系统仍然可能综合：
redirect
canonical
sitemap
站内链接
HTTPS
内容关系自行选择标准 URL。
所以：
Canonical
=
很重要的规范化信号而不是：
Canonical
=
搜索引擎必须服从的命令Self-referencing Canonical 也因此有意义：
<link rel="canonical" href="https://example.com/blog/astro" />即使当前页面已经是正式版本，也可以明确表达：
我就是这份内容的标准地址。
3.3 为什么 Astro site 配置很重要？
Canonical 通常需要完整 URL：
https://example.com/blog/astro而不是只有：
/blog/astroAstro 提供：
Astro.site再结合当前 pathname：
Astro.site
+
Astro.url.pathname
↓
Canonical URL这也是为什么项目早期没有为了“先把 canonical 做出来”，就随便配置：
https://example.comCanonical 表示正式页面身份。
因此应该等生产地址真正确定后，再配置真实：
site: 'https://真实生产域名';而不是让假域名进入生产 Metadata。
3.4 noindex：可访问，不代表应该进入搜索结果
页面可以正常打开：
用户可以访问和：
搜索引擎应该把它放进结果是两件不同的事。
因此 Layout 支持：
<meta name="robots" content="noindex" />用来表达：
这个页面可以存在，但我不希望它进入搜索索引。
例如未来某些：
测试页面
临时页面
重复内容页面
内部用途页面就可能需要这种控制。
3.5 robots.txt 和 noindex 解决的是两个不同阶段
这是非常容易混淆的一组概念。
robots.txt
→ Crawl Control
noindex
→ Index Control目前博客的 robots 策略很简单：
User-agent: *
Allow: /并提供 Sitemap 地址。
关键在于：
如果 robots.txt 已经完全禁止 crawler 访问：
Disallow: /page搜索引擎就可能读取不到 HTML 内部的：
<meta name="robots" content="noindex" />因此：
禁止 Crawling
≠
禁止 Indexing如果目的是让搜索引擎读取 noindex，通常仍然需要允许它访问页面。
这也是我真正开始区分：
Discovery
Crawling
Rendering
Indexing几个阶段的地方。
3.6 Sitemap：帮助搜索引擎发现重要 URL
搜索引擎当然可以通过站内链接发现：
Home
↓
Blog
↓
Article但一个刚上线的网站可能：
- 几乎没有外部链接
- 内容还在持续增加
- 搜索引擎还不了解整个站点结构
Sitemap 相当于网站主动提供：
这些是我希望你知道的重要 URL。
但必须记住：
进入 Sitemap
≠
一定被抓取
被抓取
≠
一定被索引
被索引
≠
一定获得排名所以 Sitemap 首先解决的是：
URL Discovery而不是：
Ranking我的 Astro 博客使用 @astrojs/sitemap 根据最终生成的路由创建 Sitemap：
Content Collection
↓
Published Routes
↓
Astro Build
↓
Sitemap没有生成页面的 draft 内容，自然也不会成为公开路由。
这让我少维护了一份独立的“SEO URL 列表”。
4. Rendering Architecture：内容什么时候真正出现？
做这个博客以后，我开始发现：
Rendering Architecture 本身也会影响内容被获取的方式。
这也是 Astro 对我最有价值的地方之一。
4.1 静态 HTML 为什么适合内容网站？
文章的构建过程基本是：
Markdown
↓
Content Collection
↓
Astro
↓
HTML用户和 crawler 拿到页面时，核心内容已经存在：
<h1>文章标题</h1>
<p>文章正文...</p>而不需要先：
下载 JavaScript
↓
初始化应用
↓
请求文章数据
↓
React / Vue Render
↓
正文才出现对于内容型网站，这意味着：
核心内容
→ 更少依赖客户端运行时才能获得4.2 但“静态 HTML = SEO 排名更高”也是误区
不能简单得出：
Astro 静态生成
→ SEO 一定比 React 好搜索引擎可以处理 JavaScript。
静态生成真正提供的是一个工程基础：
用户和 crawler 可以更直接地获得核心内容，同时减少客户端运行时成本。
它非常适合 Content-first 网站，但不是：
用了 Astro
→ Google 自动提高排名的魔法。
4.3 React 本身不是 SEO 问题
项目后来也引入了 React Island，例如 Search Command。
这时我自然产生过一个问题：
页面出现 React，是不是 SEO 就会变差？
现在我的理解是：
React
本身不是 SEO 问题真正应该问：
核心内容什么时候产生？
初始 HTML 中是否已经存在？
是否必须执行大量客户端 JS
才能得到正文和主要链接？一个搜索组件使用 React，并不意味着文章正文也变成 Client Render。
4.4 Rendering 和 Hydration 是两件不同的事
Astro Islands 让我真正区分了这两个概念。
例如：
<SearchCommand client:load />并不等于：
浏览器先下载 React
↓
React 才生成所有 HTML除 client:only 外，框架组件仍然可以先得到 HTML。
然后：
client:load控制的是：
什么时候让浏览器加载对应 JavaScript，并让已经存在的 UI 获得交互能力。
所以：
Rendering
≠
Hydration可以理解成：
Rendering
Component
↓
HTML而：
Hydration
已有 HTML
↓
加载框架 runtime
↓
绑定 state / event
↓
获得交互4.5 client:load、client:visible 和 client:only
不同 hydration directive 解决的是不同的交互优先级。
Search Command：
client:load因为：
Ctrl / Cmd + K是用户进入页面以后随时可能使用的能力。
首屏以下的复杂交互组件，则可以使用：
client:visible等接近 viewport 后再加载客户端能力。
它们主要优化的是：
客户端 JavaScript 的加载时机而不是修改页面的 SEO Metadata。
真正需要更谨慎的是：
client:only它会跳过构建 / 服务端阶段的框架 HTML 渲染。
对于真正依赖：
window
document
Canvas
WebGL
浏览器专属 API的组件，这当然可能合理。
但像：
博客正文
文章标题
导航链接
项目描述这类核心内容，没有理由为了“统一技术栈”而 client:only。
4.6 Astro-first 最终变成了一种 Content-first 架构
这个博客目前逐渐形成：
Article Content
→ Astro / Static HTML
Blog List
→ Astro / Static HTML
Hero
→ Astro + CSS
Theme
→ Astro + 少量原生 JS
Search Command
→ React Island
复杂交互
→ 按需 React Island也就是：
内容
→ 优先成为 HTML
交互
→ 按需增加 JavaScript项目最早制定 Astro-first / Why React?，主要是为了：
减少客户端 JavaScript
控制性能
避免把静态 UI React 化做到后来我才发现，这个原则同时也非常符合内容网站的 SEO 目标。
5. 信息架构与内部链接：不要让文章成为孤岛
当博客内容变多以后，仅有：
/blog
→ 按时间倒序
→ Article已经不够。
用户读完一篇文章之后，还需要回答：
接下来有什么真正相关的内容值得继续看？
因此博客逐渐增加：
Tags
Series
Related Posts最终形成：
Tag
↓
Related Articles
Series
↓
Article 1
↓
Article 2
↓
Article 3
Article
↓
Related Posts内部链接同时有两个价值。
对用户
它建立清晰的内容发现路径。
例如：
#Astro能够进入同主题内容。
Series 提供：
连续阅读路径Related Posts 则帮助读者从当前文章横向发现内容。
对搜索引擎
重要页面不应该成为：
只有 Sitemap 里存在
但站内几乎没有链接指向的孤立 URL。
所以内部链接不是简单地：
链接越多越好而更应该关注：
内容真的相关
+
Anchor Text 有意义
+
网站层级清晰这也是为什么 Related Posts 没有随机补满，而是根据：
same series
+
shared tags生成。
如果没有真正相关内容，就不强行推荐。
这一步让我开始把 SEO 从单页的：
title
description
canonical扩展到整个网站的：
Information Architecture
+
Internal Linking6. Social Metadata：分享体验和搜索排名是不同问题
博客上线以后，Metadata 不再只有搜索引擎这一条线。
还需要考虑：
页面被分享到其他平台
↓
平台怎样理解并展示它？这就是 Open Graph 和 Twitter Card 主要解决的问题。
6.1 Open Graph 不等于 Google SEO
页面目前会提供：
<meta property="og:title" />
<meta property="og:description" />
<meta property="og:type" />
<meta property="og:url" />
<meta property="og:image" />它们主要用来描述：
文章标题
描述
URL
图片
内容类型从而形成更完整的分享卡片。
因此不能简单理解成：
加入 og:title
↓
Google 排名更高我现在会把 Metadata 分成：
Page / Search Metadata
├── title
├── description
├── canonical
└── robots
Social Metadata
├── og:title
├── og:description
├── og:type
├── og:url
├── og:image
└── Twitter Card它们可以共享同一套 Content Model，但解决的问题不同。
6.2 Open Graph Image：动态生成，不等于运行时生成
每篇文章和 Project Case Study 都可以拥有自己的 OG Image。
但我的博客没有在用户分享时调用服务器实时生成图片。
而是：
Content Collection
↓
Astro build
↓
OG image generator
↓
static PNG所以：
每篇内容都有不同图片并不代表：
每次请求都动态执行图片服务它让我进一步理解了：
Build-time dynamic
≠
Runtime dynamic最终部署到生产环境中的仍然只是静态图片资源。
OG Image 能改善分享体验和内容传播，但不应该被理解成直接提升 Google 排名的手段。
7. Core Web Vitals：性能为什么会进入 SEO 讨论？
准备上线时，我开始系统检查 Core Web Vitals。
目前主要关注：
- LCP：主要内容加载体验
- INP：交互响应
- CLS：视觉稳定
我最初很容易把它们理解成：
Lighthouse 分数越高，SEO 就越好。
但这种理解太简单。
Core Web Vitals 更本质上是在描述真实用户体验。
因此性能优化的目标也不应该变成：
Lighthouse 100而是：
页面快速出现
+
交互及时响应
+
布局保持稳定7.1 Lab Data 和 Field Data 不是一回事
开发阶段我主要使用 Lighthouse：
LCP
CLS
TBT其中 TBT 可以帮助定位：
主线程长任务
JavaScript 执行阻塞但 Lighthouse 不能真正模拟大量真实用户交互，因此无法代替生产环境里的 INP 数据。
所以我的理解变成：
Lab
→ 开发阶段诊断
→ LCP / CLS / TBT
Field
→ 真实用户体验
→ LCP / CLS / INP这也让我不再把 Lighthouse 当作一个只需要“刷到 100”的评分器。
8. Search Console：网站上线以后，SEO 才真正开始
在开发阶段，我们一直是在：
向搜索引擎提供正确的信息真正上线以后，Google Search Console 才让我第一次看到：
搜索引擎实际上怎样处理这些信息这一步很重要，因为前面实现的：
title
canonical
sitemap
robots.txt都只是网站提供的信号。
最终流程仍然是：
网站上线
↓
Discovery
↓
Crawling
↓
Rendering
↓
Indexing
↓
Search Results8.1 Sitemap Success 不等于 Indexed
Search Console 中 Sitemap 显示：
Success只意味着 Google 成功读取了 Sitemap。
它不代表：
Sitemap Success
=
Indexed更不代表：
Indexed
=
获得排名这再次印证了前面的生命周期模型。
8.2 URL Inspection：第一次看到网站信号和 Google 判断的区别
通过 URL Inspection，可以分别观察：
Crawl allowed?
Indexing allowed?
User-declared canonical
Google-selected canonical这里对我最重要的一个认知是：
User-declared canonical表示：
网站认为这个 URL 是规范版本。
而：
Google-selected canonical表示 Google 实际选择的规范 URL。
所以 Canonical 再一次被验证为：
Strong Signal而不是：
Command8.3 Live Test 和 Indexed Version 也不是同一个页面状态
当我刚修复一个线上 SEO 问题时，Search Console 默认看到的 Indexed Version 可能仍然是旧内容。
而：
Test Live URL检查的是当前线上版本。
于是可能出现：
Indexed Version
→ 旧
Live URL
→ 新需要等搜索引擎重新抓取以后，两者才逐渐一致。
这让我真正把 SEO 从：
配置 Meta 标签变成：
网站提供信号
↓
搜索引擎访问网站
↓
搜索引擎独立判断
↓
最终形成索引状态9. 到目前为止，我纠正过哪些 SEO 误区？
把整个博客开发过程重新整理后，我最希望保留的反而不是“配置清单”，而是这些认知纠错。
误区一：Meta Description 就是最终 Snippet
不准确。
页面实际内容
+
Meta Description
+
搜索请求
↓
最终 Snippet误区二：<title> 就是最终搜索标题
不准确。
它是非常重要的标题信号，但并不是搜索结果必须逐字采用的指令。
误区三：Canonical 是强制命令
不准确。
它是重要的 URL 规范化信号，最终仍然由搜索系统综合判断。
误区四：robots.txt 和 noindex 是同一件事
错误。
robots.txt
→ Crawling
noindex
→ Indexing误区五：Sitemap 提交成功就代表文章被收录
错误。
Sitemap Success
≠
Crawled
≠
Indexed
≠
Ranked误区六：静态 HTML 会自动提高排名
错误。
静态 HTML 的价值在于：
核心内容更直接可获得
+
客户端运行时成本更低它不是排名保证。
误区七：用了 React，SEO 就会变差
同样错误。
真正应该关心的是：
核心内容什么时候产生？
是否存在于初始 HTML？
是否过度依赖客户端 JavaScript？误区八：Lighthouse 100 就代表 SEO 做好了
错误。
Lighthouse 是开发阶段的重要诊断工具，但真实用户体验还需要结合 Field Data 理解。
SEO 也远不只性能一个维度。
误区九：Open Graph 做得好就会直接提高 Google 排名
不准确。
Open Graph 主要解决 Social Sharing 展示。
它和 Search Metadata 有交集，但两者不能直接画等号。
10. 目前博客已经建立了哪些 SEO 基础？
现在回头看，博客的 SEO 基础已经不再是一组零散标签，而是几个相互连接的系统。
页面语义
Content Collection
Title
Meta Description
H1
Semantic HTML
lang="zh-CN"URL 与索引控制
Canonical
Astro.site
noindex
robots.txt
SitemapRendering Architecture
Static Rendering
Astro-first
React Islands
Selective Hydration
client:load
client:visible信息架构
Tags
Series
Related Posts
Internal LinksSocial Sharing
Open Graph
Twitter Card
Dynamic OG Image性能体验
LCP
INP
CLS
Lighthouse
Lab / Field Data上线验证
Search Console
URL Inspection
Live Test
Canonical Validation
Indexing Status这些能力之间不是孤立的。
它们最终共同回答：
搜索引擎能不能发现内容？
能不能稳定获取内容？
页面能不能清楚表达主题？
URL 是否稳定？
页面之间是否存在清晰关系？
用户体验是否足够好？
上线后搜索引擎实际上怎么处理它？11. 目前还没有刻意加入的能力
现在博客已经具备正常持续迭代所需要的基础 SEO 能力。
因此接下来我不会为了：
SEO Checklist 全部打勾继续机械增加功能。
例如：
Article Structured Data
JSON-LD可以在真正需要进一步描述文章实体时再学习和引入。
如果未来开始维护英文内容，再进入：
hreflang
国际化 URL
多语言 canonical如果未来出现 URL 迁移，再认真处理：
redirect
URL migration原则仍然是：
真实需求出现
↓
先理解它解决什么问题
↓
再设计实现
↓
上线验证而不是把 SEO 当成框架安装完成后的 Checklist。
12. 最终的 SEO 心智模型
如果现在让我重新总结整个过程，我会画成这样：
Content
│
┌─────────────┼─────────────┐
│ │ │
Title Description Body
│ │ │
└─────────────┼─────────────┘
↓
Semantic HTML
↓
Static Rendering
↓
┌─────────┴─────────┐
│ │
User Search Engine
│
↓
Discovery
↓
Crawling
↓
Rendering
↓
Indexing
↓
Understand / Relate
↓
Search Results
↓
Search Console旁边还有三条重要的辅助链路。
URL 身份：
Page
↓
Canonical
↓
Standard URL Signal内容关系：
Article
↓
Tags / Series / Related Posts
↓
Internal Linking客户端增强：
Static HTML
↓
React Island / Vanilla JS
↓
Selective Hydration
↓
Interaction以及分享链路：
Content Metadata
↓
Open Graph / Twitter Card
↓
Static OG Image
↓
Social Sharing现在我对 SEO 最核心的理解已经从：
关键词
+
Meta Description
+
让 Google 搜到变成：
让搜索引擎发现内容
↓
让它能够稳定获取内容
↓
让 HTML 清楚表达内容
↓
让 URL 稳定表达页面身份
↓
让页面之间形成真实的内容关系
↓
通过 Metadata 提供准确的信息
↓
减少核心内容对客户端运行时的不必要依赖
↓
持续观察真实 Crawling / Indexing 状态
↓
最终让真正有价值的内容更容易触达用户对于一个个人技术博客来说，我现在认为最重要的 SEO 基础并不是掌握多少“排名技巧”。
而是：
写真正值得搜索的内容，用稳定的 URL 承载它，用清晰的 HTML、Metadata 和内部链接描述它，并让内容本身尽可能成为 Web 的一等公民。
这也是这个 Astro 博客从一个练习项目，逐渐变成一套完整内容系统以后，我对 SEO 最大的认知变化。
Continue Reading
继续阅读
为什么我开始使用 Astro 搭建个人博客
从 Vue 技术栈出发，记录 Astro 个人技术站的搭建过程。
Discussion
参与讨论
评论由 GitHub Discussions 提供，需要使用 GitHub 账号登录后参与。