元数据、SEO 和社交

两个访问者来到你的页面,都没有像人一样查看它的方式。一个是搜索引擎,决定是否列出该页面以及如何描述它。另一个是社交平台,构建在某人分享链接时出现的小预览卡。两者都读取 <head> 中的一小块标签,而不是屏幕上的可见内容。本章是关于编写这块标签,以便你的页面在搜索结果、浏览器标签页和分享链接中正确显示。
标题和描述
每个页面都需要一个 <title>。这是浏览器标签页、书签和搜索结果列表中显示的文本。它在 head 中,是一行短代码:
<title>面包制作初学者:你的第一条面包,逐步说明</title>搜索结果中该标题下方通常有一句描述页面的句子。这来自 元描述,另一个你放在 head 中的标签:
<meta name="description" content="简单的面包配方,从混合你的第一块面团到酥脆的金色外壳,包括每个步骤的时间。" />想象一本书在书架上。标题印在书脊上,这样你就能找到它,描述是背面的宣传文字,帮助你决定是否打开它。
<title> 元素是必需的,每个文档中恰好有一个。它有三个作用:它标记浏览器标签页,当某人为页面添加书签时是默认名称,它是搜索引擎为你的结果显示的标题。为扫描列表的人编写它,将特征词放在前面,并将其保持在大约 60 个字符左右,以便不会被省略号截断。
<meta name="description"> 标签是显示在该标题下方的句子。它不是排名因素,但它是你向决定是否点击的人提出的建议,所以要具体,并为每个页面编写不同的建议。目标是大约 150 到 160 个字符。如果你忽略它,搜索引擎会从页面文本中提取片段来编写自己的摘要,它的猜测很少像你的句子那样好。
<title>面包制作初学者:你的第一条面包</title>
<meta name="description" content="分步骤的第一条面包,包括时间和常见错误的修复。" /><title> 是你完全控制的在 SERP(搜索引擎结果页,查询返回的结果列表)上显示内容的最强文本部分。值得像文案一样对待,而不是标签:特征词排在前面,因为末尾会被截断。每个人引用的字符数实际上是大约 600 像素的像素宽度限制,所以宽字符的标题比字符数建议的要更快被截断。搜索引擎也会改写他们认为不有帮助的标题,例如为了产生效果而重复一个单词的标题,或不符合查询的标题,所以清晰、准确的标题比填充的标题更有可能幸存。
描述不是排名的输入。它唯一的工作是 点击通过率,看到你的结果并点击它的人的份额,一个更清晰的描述会提升那个份额。两条生产规则比长度更重要。首先,每个页面都有自己的标题和描述;在整个模板化网站上发送一个全局对,意味着近乎相同的结果相互竞争,读起来像样板。其次,在从数据构建页面的网站上,从页面自己的字段生成两者,而不是固定字符串,这样产品页面会命名其产品,配方页面会命名其配方。
<title> 是你的标签页标签和人们在搜索结果中点击的标题,所以要清晰。<meta name="description"> 是下面的宣传文字。两者都在 head 中,给每个页面分配自己的对比我预期的要求少得多的工作量,但能帮助很多。 <title>,特征词在前,大约 60 个字符。描述不影响排名,它只赢得点击,所以为每个页面编写一个特定的,而不是一条全局线。忽略它,引擎会发明一个你没有选择的片段。 字符集和视口,再访
你的第一个 HTML 页面中的骨架以两个快速粘贴和忘记的 meta 标签开头。值得再看一眼,因为两者都改变了如何在任何内容出现之前读取和呈现页面。
第一个标签是字符编码:
<meta charset="UTF-8" />它告诉浏览器字母是用哪种字母表写的,所以带重音符号的字符、卷曲引号和表情符号正确显示,而不是变成奇怪的符号。总是使用 UTF-8;它涵盖每种语言和每个表情符号。
第二个标签是 视口,它使页面适合手机屏幕:
<meta name="viewport" content="width=device-width, initial-scale=1" />没有它,手机假设页面是为宽桌面构建的,并将整个内容缩小到文本太小而无法阅读。有了它,页面就匹配设备的宽度。把它想象成告诉浏览器它要打印的纸张的真实大小。
<meta charset="UTF-8"> 设置字符编码,从文件的原始字节到它们代表的字符的映射。它必须出现在早期,在文档的前 1024 字节内,并作为 head 中的第一件事,因为解析器需要在解码后面的文本之前知道编码。UTF-8 是你应该使用的唯一答案;它编码每种语言中的每个字符。
<meta name="viewport" content="width=device-width, initial-scale=1"> 是使页面在手机上响应式的原因。width=device-width 将页面的布局宽度与设备自身的宽度相匹配,initial-scale=1 以正常缩放而不是缩小状态打开它。忽略此标签,移动浏览器会退回到假设大约 980 像素的桌面布局,然后缩放以适应。不要添加 user-scalable=no 或 maximum-scale 来锁定缩放;它阻止人们捏合放大文本,许多读者都依赖这一点。
字符集声明存在是因为解析是一个两阶段的问题:浏览器有一个字节流,需要一个编码来将它们转换为字符。如果编码声明较晚,或与解析器从前几个字节中猜测的冲突,浏览器可以丢弃其工作并从头开始以正确的编码重新解析,这是你通过首先放置 <meta charset="UTF-8"> 来避免的小成本。如果响应还在其 HTTP Content-Type 标头中携带 charset,标头获胜,但你仍然包括 meta 标签,以便文件在保存或不带该标头的情况下提供时是正确的。UTF-8 是网络的既定默认值;其他任何东西都是要迁移的遗留情况。
视口标签是两种呈现模式之间的开关。没有它,移动浏览器呈现为宽虚拟画布(历史上大约 980 个 CSS 像素)并缩放结果,这就是为什么未标记的页面看起来像缩小的桌面。width=device-width 将布局视口绑定到设备,这是任何响应式 CSS 行为的前提条件。用 user-scalable=no 或低 maximum-scale 抑制缩放是无障碍失败:在 WCAG(网络内容无障碍指南,无障碍网络内容的标准参考,涵盖在无障碍中)中被强调,因为它阻止人们放大他们无法阅读的文本。
<meta charset="UTF-8"> 使带重音符号的字母和表情符号不会变成乱码,所以总是包括它。视口线使页面适应手机,而不是缩小到微小的桌面。两个标签你复制一次,很少再碰,但跳过它们会很快显示出来。 UTF-8,别的都不用。带有 width=device-width 的视口标签是使响应式 CSS 在手机上工作的原因,永远不要禁用缩放,人们依赖它。 user-scalable=no 锁定缩放会失败 WCAG,所以忽略它。 Open Graph 和社交卡
当你把链接粘贴到聊天或社交帖子中时,小预览卡通常会出现,其中包含图片、标题和一行文本。该卡不是平台在猜测。页面使用称为 head 中的 Open Graph 的一组标签向其提供图片和单词:
<meta property="og:title" content="面包制作初学者" />
<meta property="og:description" content="你的第一条面包,逐步说明。" />
<meta property="og:image" content="https://breadschool.example/loaf.jpg" />注意这些使用 property,而前面的描述标签使用 name。那就是 Open Graph 标签采用的形式;复制模式并更改单词和图像地址。把它想象成将小预览打包到页面中,随时准备在某人分享它时使用。
Open Graph 是描述页面作为可共享对象的 meta 标签的共享词汇。它始于 Facebook,现在被几乎每个显示链接预览的平台读取。标签使用 property="og:..." 和基本的是五个:
<meta property="og:title" content="面包制作初学者" />
<meta property="og:description" content="你的第一条面包,逐步说明,包括时间。" />
<meta property="og:image" content="https://breadschool.example/loaf.jpg" />
<meta property="og:url" content="https://breadschool.example/sourdough" />
<meta property="og:type" content="article" />Twitter,现在是 X,读取它自己的 twitter: 标签,但退回到 Open Graph 标签,所以你只需要添加改变布局的部分:
<meta name="twitter:card" content="summary_large_image" />这给你大图像卡,而不是小缩略图。使 og:image 大约 1200 乘 630 像素,以便它整洁地填充卡,在你依赖它之前在平台自己的链接预览调试器中检查你的结果。
这些标签的受众是 社交爬虫:当链接被发布时平台运行的机器人,它获取页面,仅读取 head,并且不滚动、点击或通常运行 JavaScript。关于你如何编写 Open Graph 的一切都源于此。og:image 必须是绝对 URL,包括 https:// 和域,因为相对路径如 /loaf.jpg 当远程爬虫读取它时没有页面上下文来解析。标签使用 property 属性而不是 name,因为 Open Graph 在 RDFa 中定义,这是在标记中嵌入结构化数据的较旧标准;实际的收获是仅 og: 标签使用 property,你不应该将其"更正"为 name。
两个生产现实会让人出错。首先,平台缓存他们爬取的卡,所以编辑你的标签不会更新已分享的链接,直到你通过平台的调试器强制重新爬取。其次,因为大多数爬虫不运行 JavaScript,由单页应用在客户端注入的 Open Graph 标签往往根本看不到;卡退回到裸标题或空。如果你的页面由 JavaScript 构建,修复是在服务器上呈现 head,以便标签出现在爬虫读取的第一个响应中。这是与塑造爬取的相同约束,下一节会讲到。
og:title、og:description 和 og:image。它们使用 property 而不是 name,这一开始看起来很奇怪,但就是这样写的。设置它们,你的链接就不会赤裸地显示。 og:title、og:description、og:image、og:url、og:type。添加设置为 summary_large_image 的 twitter:card 以获得大图像,并将图像大小设置在 1200 乘 630 左右。在你信任它之前,始终在平台调试器中检查卡。 og:image 会无声地失败。平台缓存卡,所以更改需要在他们的调试器中强制重新爬取。客户端呈现的标签通常永远看不到,这就是为什么 JavaScript 应用必须在服务器上呈现 head。 Favicon 和其他链接标签
浏览器标签页中的小图标,在页面标题旁边,是 favicon。它是某人在十几个其他标签中找到你的标签页的方式。你用 head 中的 <link> 标签添加一个:
<link rel="icon" href="/favicon.png" />rel="icon" 部分告诉浏览器这个文件是页面的图标,href 指向图像。一个小方形图像,大约 32 乘 32 像素,已经足够。这是一个小触摸,它使网站看起来完成了。
<link> 元素将你的页面连接到相关文件,rel 属性说明该文件是什么。favicon 使用 rel="icon",现代 PNG 或 SVG 是比旧 .ico 格式更好的选择。也添加 Apple 触摸图标,这是 iOS 在某人将你的网站保存到他们的主屏幕时使用的图像:
<link rel="icon" href="/favicon.svg" />
<link rel="apple-touch-icon" href="/apple-touch-icon.png" />另一个 <link> 值得在这里出现:规范 URL。当同一页面可从多个地址到达时,例如有或没有尾部斜杠或末尾有跟踪参数,rel="canonical" 命名你想被视为真实的地址:
<link rel="canonical" href="https://breadschool.example/sourdough" />这告诉搜索引擎将所有副本的信用分配给该单个 URL,而不是将页面的声誉分散在它们之间。
rel 属性是一个关系关键字:它说明链接的资源与此文档的关系,这就是为什么一个元素涵盖图标、规范、样式表和预加载。对于图标,浏览器接受多个并按大小和格式选择;SVG 图标无需每个大小的单独文件就可以缩放到任何显示,并为旧浏览器提供 PNG 后备。遗留 favicon.ico 是为了兼容而保留的多分辨率格式,不再是首先要使用的格式。
规范链接是有真实排名后果的那个,所以值得精确获取。它将 链接权益,通过指向页面的链接传递的排名值,合并到你指定的 URL 中,而不是分散在重复地址中。良好实践是每个页面上的自引用规范(每个页面命名其自己的干净 URL),这在出现参数或备用路径时消除歧义。失败模式是指向错误的页面的规范:在整个部分硬编码一个规范的模板告诉搜索引擎该部分中的每个页面都是其中一个的副本,其他页面从索引中掉出。其他 rel 值,如 preload 和 preconnect,是性能提示,它们早期获取或预热与资源的连接;它们属于页面速度讨论,而不是这个讨论,所以将它们视为指针,而不是这里的任务。
<link rel="icon"> 和小方形图像添加。这是一个使网站感觉完成的小东西。head 中的 <link> 标签是你如何将页面指向额外文件如此的方式。 rel="icon" 和 PNG 或 SVG 而不是旧 .ico,并添加 apple-touch-icon 用于保存到主屏幕。规范链接,rel="canonical",在页面可从多个位置到达时命名真实地址,所以搜索引擎信用一个 URL 而不是分散它。 rel 是一个关系关键字,这就是为什么一个元素处理图标、规范和预加载。SVG 图标无需每个大小的文件就可以缩放。规范是高风险的:每个页面的自引用规范是安全的,但指向一个 URL 的模板会让其他页面从索引中掉出。 可爬取性基础
搜索引擎发送程序来访问网页,读取它们,并将它们添加到一个大列表中,以便人们稍后可以找到它们。该程序是 爬虫,大多数情况下你希望它完成工作,你不做任何特殊操作。如果你有一个你宁愿保留在搜索之外的页面,一个粗略的草稿或私人感谢页面,你用 robots meta 标签说明这一点:
<meta name="robots" content="noindex" />noindex 意思是"请不要在搜索结果中列出此页面。"想象爬虫是一个图书管理员在书架上走,为每本书编目;这个标签是一个请求图书管理员跳过这本书的便条。
爬虫读取你的 HTML,跟随它找到的链接以到达更多页面,并索引内容以便它可以在结果中提供它。你用 robots meta 标签引导它。noindex 将页面保留在结果之外,nofollow 告诉爬虫不要通过页面上的链接传递任何排名信用:
<meta name="robots" content="noindex, nofollow" />不要将其与 robots.txt 混淆,这是你网站根目录中的一个单独文件,控制爬虫允许获取哪些页面。meta 标签控制爬虫已经到达的页面的索引;该文件控制访问。
完全跳过旧的 <meta name="keywords"> 标签。它曾让页面列出自己的关键词,搜索引擎多年前停止相信它,它今天什么都不做。实际上帮助页面排名的是普通的好的构建:清晰的标题、真实的标题、语义 HTML 命名页面的每个部分、描述性的链接文本和快速加载的页面。
将搜索引擎采取的三个步骤分开会有所帮助,因为标签作用于不同的步骤。爬取是获取页面。索引是为以后存储和理解它。排名是针对给定查询订购它相对于其他页面。带有 noindex 的 robots meta 标签作用于索引;robots.txt 作用于爬取;X-Robots-Tag HTTP 标头可将相同的索引规则应用于非 HTML 文件如 PDF。经典错误是在 robots.txt 中阻止页面并也在其中添加 noindex:爬虫不被允许获取页面,所以它永远看不到 noindex,URL 可以在没有描述的结果中徘徊。如果你想让页面摆脱索引,让它被爬取,让 noindex 被读取。
现代爬虫确实呈现 JavaScript,但有延迟和预算限制,所以仅在客户端获取后出现的内容被缓慢或根本不被索引;可靠的答案是服务器呈现任何必须被找到的东西。为了以搜索引擎可以直接使用的形式描述页面,添加 结构化数据,关于页面的机器可读事实。标准方式是 JSON-LD 块,使用 Schema.org 词汇用 JSON 编写的结构化数据,放在 head 或 body 内的 <script type="application/ld+json"> 标签中:
{
"@context": "https://schema.org",
"@type": "Recipe",
"name": "初学者面包",
"totalTime": "PT24H",
"recipeYield": "1 条面包"
}这本身不会提高你的排名;它使页面有资格获得 丰富结果,SERP 上带有星星、价格或配方详细信息等的增强列表。至于排名本身,大多数人调整的是神话。keywords meta 标签自 2009 年左右以来就被忽略了。重复关键词似乎更相关会被检测到并会对你有负面影响。描述不是排名输入。一致获胜的是回答查询的内容、使结构清晰的语义标记、来自其他网站的链接和快速稳定加载的页面。本章中的标签使页面可展示并被正确理解;它们不能替代页面值得排名。
<meta name="robots" content="noindex">。那是在这个阶段你会到达的主要旋钮,所以不需要对其余的过度思考。 noindex、nofollow);单独的 robots.txt 文件控制爬取。旧的 keywords meta 标签是已死,所以忽略它。真实排名来自清晰的标题、语义 HTML、好的链接和快速的页面,不是来自魔法标签。 robots.txt 中阻止页面并添加 noindex,因为爬虫永远不会获取页面来读取标签。JSON-LD 赢得丰富结果,不是排名提升。关键词元已死;内容和语义是实际获胜的。 
