站内优化：标题、描述、链接与页面结构
这一篇把上一节的方法页改成有明确标题、摘要、主标题与规范网址的完整页面。成品先看这组已经填好的内容：
| 位置 | 本页写法 |
|---|---|
| 浏览器与HTML标题 | Review an English app description | ClearCopy |
| 页面主标题 | Review an English app description against the product facts |
| 摘要 | Compare an English app description with the product facts. Follow three steps and see an offline packing-list example. |
| 规范路径 | /guides/english-app-description/ |
| 下一步链接 | Check a short description with ClearCopy，指向/check |
它们都在说同一件事：教读者按真实功能核对英文介绍。没有突然变成“让你的App排名第一”，也没有把每一页都起名为“Home”。你会实际构建并在HTML里找到这些值，而不只在编辑器里填一张SEO表。
先把标题与主标题写成两种用途
title告诉浏览器标签和搜索系统这张页面是什么；h1是读者进页面后看到的主标题。两者不必逐字一致，但应该承诺同一份内容。本页的title保留较短主题与品牌，h1把“按功能事实核对”说完整。
Google标题说明实际建议使用清楚、简洁的标题，搜索展示也可能根据页面其他内容自动形成标题链接。它没有要求每个标题恰好60个字符；设备宽度与展示方式会影响截断。先删掉重复的品牌、形容词与同义词，胜过机械数到某个字符就停止。
配图中的官方示意把浏览器页面标题与HTML的title元素对应起来。看图时注意它和正文大标题的位置不同。以后遇到标签名已经改了、页面大标题没变，就知道该分别检查哪个元素。
给Astro一个能生成绝对网址的站点地址
在web/astro.config.mjs中添加site，保留原有本地API代理：
import { defineConfig } from 'astro/config';
export default defineConfig({
site: process.env.SITE_URL || 'http://127.0.0.1:4301',
vite: {
server: { proxy: { '/api': 'http://127.0.0.1:4301' } }
}
});
本地默认值只用于本篇练习。正式发布前，SITE_URL要设为自己的真实HTTPS站点根地址，例如你已经生成的Railway域名，不带/check。这里的本机地址不是可以公开沿用的canonical。
规范网址告诉搜索系统你希望采用哪个版本。比如推广链接带了?source=community，正文仍是同一篇方法页，就使用不带这项追踪参数的规范地址；不要让每个渠道参数都变成另一篇文章，也不要把站里所有教程都指向首页。Google规范网址说明把它视为选择规范版本的信号，最终还会由Google处理，并非一道必须服从的命令。
在页面里填入一份可以直接使用的head
打开web/src/pages/guides/english-app-description.astro，在HTML前面加上这段Astro前置信息：
---
const title = 'Review an English app description | ClearCopy';
const description = 'Compare an English app description with the product facts. Follow three steps and see an offline packing-list example.';
const canonical = new URL(
'/guides/english-app-description/', Astro.site
).href;
---
接着把原来的head替换成下面这段，正文继续保留上一节已写好的方法与例子：
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1" />
<title>{title}</title>
<meta name="description" content={description} />
<link rel="canonical" href={canonical} />
</head>
description写的是本页实际提供的内容：三步方法与离线行李清单例子，不额外承诺流量、收入或审核结果。Google摘要说明指出搜索摘要主要来自页面内容，也可能使用meta description。所以摘要填好之后，正文同样要兑现它；不能首页只有一个输入框，摘要却说有完整案例库。
让正文层次和链接接住摘要
本页已经有一个h1。正文把三步方法放进有序列表，再用h2引出完整短例子，读者扫标题就能知道怎样使用。如果每段都使用h1，或者为了文字变大随意挑标题级别，就不容易表达这种结构。字体大小由样式调整，标题级别负责内容关系。
页面最后的链接使用普通HTML：
<a href="/check">Check a short description with ClearCopy</a>
这条链接的下一页是工具，不是另一个还没写完的SEO目录。你可以在工具页结果解释旁反向加入“Read the three-step review method”，指向本页。等同步说明与完整样例真正写好，再加入它们的链接，不提前把读者送去404。
Google链接实践强调带href的可抓取链接与有意义的链接文字。本书采用的就是这个朴素形式，不需要为了SEO给每段加一串相同关键词。
构建后看结果，不停在源文件
在项目根目录运行npm run build，用编辑器打开web/dist/guides/english-app-description/index.html，搜索title、description、canonical与h1。本书实际构建后的结果包括：
<title>Review an English app description | ClearCopy</title>
<link rel="canonical"
href="http://127.0.0.1:4301/guides/english-app-description/">
<h1>Review an English app description against the product facts</h1>
description也与前面的已填内容一致。这个本地canonical正说明构建时读取到了默认站点地址；它不是公网SEO完成的证明。
准备上线时，在Railway服务变量里设置真实的SITE_URL并重新构建。若沿用第三章Dockerfile，运行npm run build之前还需添加下面两行，让构建阶段可以读取该公开配置：
ARG SITE_URL
ENV SITE_URL=${SITE_URL}
SITE_URL是公开站点地址，不是密钥。重新部署后查看公开HTML，确认canonical已经换成实际HTTPS域名；不要因为运行环境里添加了变量，就假设之前已生成的静态HTML会自动改写。仍指向本机时，检查变量是否进入构建阶段、旧构建是否仍在提供服务。
你已经有一张标题与正文一致、摘要有内容支撑、链接有明确去处的方法页。把这一套做法应用到其余页面时，先换每页的实际任务、摘要和路径，别只复制同一个head。以后搜索展示与预期不同，再结合具体查询和页面内容调整，而不是把整个站点的标题一起换掉。