这几日我已经逐步完成了我的博客的重新搭建, 熟悉了Markdown的写作流程, 对主题也进行了一些修改, 甚至自学了一下PHP😂. 慢慢的我开始关注起了我的网站在搜索引擎中的索引量...
前提声明我没有学习过任何SEO的知识以下内容只是我在建站过程中的一些探索心得, 我的博客文章并不多, 但基本所有都是原创文章. 但我不是那么的在意访问人数有多少, 只是觉得要是别人遇到的问题我刚好遇到过爬了坑要是别人能在搜索引擎上很快的搜索到我的解决方案, 是不是一切都那么的简单加轻松愉快啦...😊 so 探索吧.
以下优化经验来自于谷歌搜索参考文档
检查已经被搜索引擎索引的页面
在所有搜索引擎中可以在搜索框使用 site:{你的域名} 如 site:nenufm.com 查看当前网站已经被索引的页面. site: 查询是一个搜索运算符，您可以使用它请求来自运算符中指定的特定网域、网址或网址前缀的搜索结果。当然基本所有搜索引擎都会有一个站长后台, 你在这里搜索它也会提示你, 你是否是这个网站的站长,让你进入站长后台进行管理... 站长后台的坑我之后再说.
问题思考
在搜索结果中我发现以下几个在我想法之外的问题.
搜索结果界面包含隐私政策页面
我搜索了以下每个网站都有隐私政策页面, Wordpress也会生成一个/privacy-policy页面, 这是大概是每个网站所必须要求的界面吧. 但是我不希望它出现在我网站搜索结果里面. 我设想了一个场景比如在百度上有人搜索 留声与视 这个关键词出现了一个结果 隐私政策 - 留声与视 我觉得稍微有那么一点诡异.
搜索结果包含分类,标签页面
我不太清楚是因为我的网站文章内容太少,还是我写作的时候喜欢打标签,分类,在我搜索本站的搜索结果中我看到了搜索结果靠后的大量本站的标签页.我认为...🤣 至少现在我觉得, 分类或者标签都是用来用户在站点里面查找同类文章用的, 在搜索结果中往往不太适合. 更多的我希望用户是直接搜索到我博客的具体文章, 而不是搜索了之后跳转到一个拥有很多文章的分类或者是标签. 或许分类确实有用, 等之后文章多起来了我或许会希望它出现在搜索结果中.但现在暂时不用.
搜索优化
对于以上问题我开始的想法是在 robots.txt 直接屏蔽掉有关路径. 但我在谷歌搜索文档中看到以下提示警告
google search docs robots: robots.txt 文件规定了搜索引擎抓取工具可以访问您网站上的哪些网址。 此文件主要用于避免您的网站收到过多请求；它并不是一种阻止 Google 抓取某个网页的机制。若想阻止 Google 访问某个网页，请使用 noindex 禁止将其编入索引，或使用密码保护该网页。
似乎 robots.txt 里面所屏蔽的是直接让搜索引擎不去理解这个目录下面的所有内容, 属于非常强烈激烈的声明, Google的意思robots.txt更像是在爬虫阶段就直接禁止了, 爬虫就会直接中断爬取对应地址的链接. 数据没有进入搜索引擎进行分析. 例如如果我直接在 robots.txt 屏蔽了 /privacy-policy 路径的访问搜索引擎会认为我的网站没有隐私政策页面. 而我希望的只是它不显示在搜索结果里面而已.
这是我原始的 robots.txt
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /wp-includes/
Disallow: /wp-content/plugins/
Disallow: /wp-content/themes/
Sitemap: https://nenufm.com/sitemap.xml在文档中我看到这么一段描述
资源文件: 如果您认为在加载网页时跳过诸如不重要的图片、脚本或样式文件之类的资源不会对网页造成太大影响，您可以使用 robots.txt 文件屏蔽此类资源。不过，如果缺少此类资源会导致 Google 抓取工具更难解读网页，请勿屏蔽此类资源，否则 Google 将无法有效分析有赖于此类资源的网页。
我暂时性的认为在 robots.txt 中屏蔽 主题和插件里面的内容或许不是一个很好的方案. 最后我将robots.txt 文件修改为了这个样子, 只屏蔽了 Wordpress 的后台页面.
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Sitemap: https://nenufm.com/sitemap.xml建议的优化方案
在 google search docs block-indexing章节中搜索引擎更建议使用 noindex 方案, 其中支持在文档头里面添加 <meta name="robots" content="noindex" /> 或者在http响应头里添加X-Robots-Tag: noindex, 在响应头里添加个人觉得过于复杂. 最后我在分类,标签页中都添加了如下代码. 阻止搜索引擎索引.
<!doctype html>
<html>
<head>
...
<meta name="robots" content="noindex" />
...
</head>
</html>
<meta name="robots" content="noindex, nofollow" />对于隐私页面我在原本我在网上拷贝的备案填写信息中发现了一些配置在 google search docs qualify-outbound-links
<!-- 备案页面声明 希望 Google 不跟踪您网站上的出站链接，或不从您的网站上抓取链接页-->
<a href="https://beian.miit.gov.cn" target="_blank" rel="nofollow noopener">蜀ICP备16022835号-1</a>
<!-- noindex 不索引当前页面, nofollow 不索引出站链接 -->
<a href="https://nenufm.com/privacy-policy" target="_blank" rel="noindex, nofollow">隐私政策</a>对于整个文档我也修改优化了一下 添加了 lang="zh" 声明中文页面, 主打一个别人也有我也要有的原则.😂 印象中好像在哪里看到过对于全球化搜索引擎页面最好声明语言类型.
<!doctype html>
<html lang="zh">
...
</html>2023-10-30 补记
最后我给分类页和标签页加上了 noindex。这些页面仍然保留在博客里，方便读者按主题浏览，也允许搜索引擎继续访问其中的文章链接，但它们本身不再进入搜索结果。
当时站内文章不多，搜索结果里却出现了大量分类和标签页面。它们的内容高度重复，又挤在具体文章前后，对读者没有多少帮助，也会分散原本应该落到文章上的搜索入口。相比彻底禁止爬虫访问，我真正想做的只是让搜索引擎收录文章，而不是把每个分类和标签都当成一个独立结果。
2026 年重新检查：从 WordPress 迁移到 Next.js 之后
几年后，博客已经从 WordPress 迁移到 Next.js，公开文章也有了 75 篇。我原以为站点地图、canonical、robots 和结构化数据都配好了，接下来只要等搜索引擎慢慢收录。实际并非如此：Google Search Console 能看到网站，但真正从搜索获得展示的文章仍然很少；Bing Webmaster Tools 还提醒我，一篇本地 AI 编程文章的搜索摘要太短。
只改被点名的页面很容易，但我更想知道它是不是孤例，于是重新检查了全部公开文章。
摘要要让人知道文章能解决什么
早期文章的摘要有些只有一句泛泛的介绍，有些又长得像正文开头。更麻烦的是，迁移过程中曾经留下两份摘要，同一篇文章在后台看到的是新内容，搜索页面拿到的却可能还是旧版本。
整理后，每篇文章只保留一份公开摘要。技术文章尽量在 120 至 160 个字符内交代三个问题：文章在处理什么、适合谁看、正文能提供什么。这个长度只是写作时的参考，不是必须卡住的考试分数。
生活随笔和诗歌不适合这样处理。它们本来就不是问题解答，硬塞进一段“主题、价值和要点”，读起来只会像宣传文案。这次仍有 6 篇生活文章保留了短摘要，我没有为了让统计数字好看而继续补字。
看起来像标题，不一定真的是标题
页面上的文章标题一直很醒目，我以前也就默认它没有问题。检查网页结构后才发现，视觉上的大字不一定是搜索引擎理解的一级标题；有些正文又重复写了一遍标题，或者把普通章节也写成一级标题。
现在每篇文章只保留一个明确的 H1，下面再按内容使用 H2 和 H3。这个调整对页面外观影响不大，却让文章的主题和章节关系清楚了许多。
旧链接和短文章要逐篇判断
从 WordPress 迁移过来的文章中还留着一些旧地址。它们即使暂时还能跳转，也会让搜索引擎多绕一步，读者复制的还是已经废弃的链接。我把能够确认对应关系的旧链接改成了现在的文章地址。
短文章则不能只看字数。SQL Server 和 Gradle 文章的说明不长，但有完整的样例数据、查询过程和配置代码，它们并不缺内容。另一些文章确实只有一句结论，读者看完仍然不知道怎么操作，我才补上判断步骤、验证方法和容易踩到的边界。
这次整理让我重新划清了一条线：短不等于薄，长也不等于有用。关键还是读者能不能从文章中得到一个完整答案。
搜索控制台的数据不会马上变化
文章整理完并不意味着 Google 或 Bing 会立即重新抓取。搜索控制台里的汇总数字有延迟，“已排除”也不一定代表故障，其中可能包含主动不参与搜索的分类页、标签页、Feed 和旧地址。
相比反复盯着总数，我现在更关心具体页面。Google 关于检查单个网页的排查说明给出的检查项也包括抓取、canonical 和索引状态：页面能不能被抓取，canonical 是否正确，是否允许索引，站点地图有没有提交，以及搜索引擎最后选择了哪个版本。把这些问题分开看，才能知道网站是真的有故障，还是还在等待下一次抓取。
首页已经收录，但不代表站名一定能搜到
2026 年 7 月 30 日，我又专门检查了一次首页。Search Console 显示首页已经被 Google 收录，抓取成功，允许索引，Google 选择的 canonical 也是 https://nenufm.com/。站点地图读取成功，人工处置措施和安全问题也都没有异常。
但我直接搜索“留声与视”时，第一页仍然没有首页。Google 更倾向于把这个词理解成声音、影像或影视作品。加上域名搜索“留声与视 nenufm”之后，首页才排在第一条；单独搜索“nenufm”，首页当时排在第二条。
这次检查让我真正分清了收录和排名。收录表示页面已经进入 Google 的系统，不等于它会在每个看似相关的关键词下出现。Google 对搜索过程的说明也把抓取、索引和呈现搜索结果分成了不同阶段。以后再遇到“搜不到”，先检查具体网址的索引状态，再判断是技术故障还是查询匹配问题。
关于页不该和分类页一起 noindex
排查首页时，我发现 /about 一直带着 noindex，也没有进入站点地图。分类页和标签页内容重复，继续保持 noindex 没有问题；关于页不同，它本来就负责说明这个网站是谁、写什么以及为什么存在。
更尴尬的是，关于页还保留着旧的网站简介：“从未如此简单有趣。”这句话放在当年的博客里没什么问题，现在却无法说明网站已经在写 AI、软件开发、互联网见闻和日常生活。
最后我让关于页恢复索引并加入站点地图，删除重复的摘要字段，也重新写了开头和网站简介。现在它先说明“留声与视”是一个个人博客，再介绍作者、写作方向和建站原因。这里没有堆关键词，只是把原本含糊的信息说清楚。
文章里的作者链接应该指向哪里
关于页整理好以后，我又开始琢磨文章标题下面的作者链接。它直接指向 /about，会不会让搜索引擎分不清网站和作者的关系？我一度想改成 /about#联系，让链接直接落到联系方式。
查过文档后发现，重点并不在这个锚点。联系章节说明的是怎样找到作者，不是作者是谁；#联系 也只是把读者带到同一个页面中的某个位置。真正能把文章和作者介绍页明确关联起来的是文章的结构化数据。
Google 明确建议使用 author.url 指向能够唯一说明作者身份的个人介绍页、作者页或 About 页面。Google Article 结构化数据指南中的这条建议对我很重要，因为 /about 原本就同时承担了介绍作者和网站的作用，没有必要再为作者单独造一个页面。
我保留了页面上“作者：太阳”到 /about 的链接，同时在每篇文章的 BlogPosting JSON-LD 中加入作者地址：
{
"author": {
"@type": "Person",
"name": "太阳",
"url": "https://nenufm.com/about"
}
}这样，可见链接负责让读者进入介绍页，author.url 则告诉搜索引擎这个 Person 对应哪个页面。结构化数据中的网站发布者仍然是 Organization，作者仍然是 Person，两者没有混在一起。
中文标题不是越大越清楚
我以前觉得标题越大，主题就越醒目。实际把中文文章放到页面上看，效果正好相反：几十个笔画复杂的汉字使用接近 48 像素的粗黑字体以后，整行更像一块黑色画面，眼睛反而不容易快速认出每个字。
这次把文章主标题控制在约 30 像素，正文二级和三级标题分别控制在约 24 和 20 像素，字重也从特别粗改成普通粗体。关于页还有一处“关于”的重复：顶部导航、面包屑和正文标题连续出现三次。我删掉了一级固定页面里没有实际导航价值的面包屑，只保留当前导航状态和 H1。
这些调整不是为了直接换取搜索排名。H1、H2 和 H3 的结构原本已经正确，变化主要发生在阅读体验上。页面首先要让人愿意读，SEO 才有继续讨论的意义。
2026-08-22 排查：索引量低，到底低在哪里
这次我从 Google Search Console 导出了抓取统计和网页索引报告。表面上看，Google 已知 199 个网址，只索引了 64 个，比例不高。但把未索引原因拆开后，情况没有这个数字看起来那么严重。
135 个未索引网址中，86 个带有 noindex，8 个会自动重定向，17 个返回 404，另有 1 个被 robots.txt 屏蔽。真正由 Google 暂时没有选择索引的，是 7 个“已抓取，尚未编入索引”和 16 个“已发现，尚未编入索引”。后者在 Search Console 中已经通过验证，但汇总数字仍未刷新。
86 个 noindex 大多是文章列表、分类、标签和分页。这些页面用于站内导航，没有独立正文，本来就不在索引目标里。把它们算进分母，再拿 64 除以 199，会把索引率看得过低。当前真正希望进入搜索结果的是首页、关于页和 113 篇公开文章，站点地图一共包含 115 个网址。
这里还有一个时间差。Search Console 在 2026 年 7 月 31 日最后一次读取站点地图，当时只发现 79 个网址；排查当天的站点地图已经增加到 115 个。按 Google 实际读取到的数量粗略计算，64 除以 79 约为 81%。直接拿 64 和现在的 115 比较只有约 56%，但两边不是同一时间的数据。网页索引图表也只更新到 8 月 17 日，不能拿它判断之后发布的文章。
抓取没有被全站阻断
抓取统计覆盖 2026 年 7 月 6 日至 8 月 19 日，共记录 3734 次请求，其中 HTML 请求 1177 次。约 90.63% 返回 200，4.85% 返回 404，3.88% 是永久重定向。全部资源的平均响应时间约为 722 毫秒，HTML 约为 966 毫秒。
Google 在 7 月 7 日和 8 日集中抓取了 1762 次，占整个周期的 47.2%，之后仍在持续访问。86.58% 的请求用于刷新已知网址，13.42% 用于发现新网址。这说明 Google 已经知道站内的大部分结构，当前工作更多是复查，而不是完全找不到文章。
我又检查了排查当天站点地图中的全部 115 个网址：全部返回 200，有自指 canonical，允许索引，也都有明确的 H1，没有发现重复标题。robots.txt 可以正常访问并允许抓取，站点地图地址也正确。从首页进行一次站内爬行，共访问 223 个页面，没有遇到失败链接。
这些结果排除了一个最担心的情况：当前没有错误的 robots.txt、全站 noindex、canonical 指向错误或大面积服务器故障。抓取正常只说明页面可以交给 Google 处理，不能保证它一定进入索引。Google 对网页索引报告的说明也把“已抓取，尚未编入索引”和“已发现，尚未编入索引”分开处理。
404 和重定向要看具体网址
抓取统计中大约有 181 次 404，这个比例值得继续查，但不能看到 404 就全部重定向。站内爬行没有找到当前失效链接，站点地图也全部返回 200，因此这些请求更可能来自旧博客地址、外部网站保留的历史链接、已经删除的静态资源，或者同一域名下的其他服务。
确实有替代文章的旧地址应该永久重定向；已经删除且没有替代内容的网址保持 404 才是正确结果。下一步需要从 Search Console 分别导出 17 个 404 和 1 个被 robots.txt 屏蔽的网址，再逐个核对，不能只凭汇总数量修改规则。
这次排查后的处理顺序
这次之后可以重新提交一次现有站点地图，让 Google 重新读取已经从 79 增长到 115 个的网址集合。相同的站点地图不需要每天重复提交，也不应该为了催促抓取而批量修改文章日期或 lastmod。Google 的站点地图文档说明，站点地图用于提供网址发现和规范化信号，并不保证页面进入索引。
接下来先观察站点地图的上次读取时间和已发现网页数，再检查那 7 个“已抓取，尚未编入索引”的具体文章。如果它们长期没有变化，再判断内容是不是太薄、主题是否与其他文章重叠，以及内部链接能否说明它的重要性。分类、标签和分页继续保持 noindex, follow，没有必要为了让统计数字变好而把它们全部开放索引。
这次数据给我的结论很直接：索引量看起来低，主要是因为 Search Console 把主动排除的导航页面也算进了已知网址，同时站点地图和网页索引报告存在时间差。当前仍有 404、历史可用性和少量未选入索引的文章需要继续处理，但没有发现一个可以靠修改全站 SEO 配置立即解决的故障。
2026-08-25 补记：手动提交之后，我又回头检查首页
最近我把站内规范网址通过百度普通收录 API 分批提交。提交之后，百度的索引量才开始上涨。这件事让我没法继续用“搜索引擎只是需要时间”来安慰自己。
但我也不能据此断定网站和文章完全没有问题。API 返回成功，只表示百度接受了这些网址，不等于已经收录；索引量随后上涨，也只能说明手动提交可能帮助百度更快发现或重新处理页面。它至少给了我一个线索：文章本身未必是唯一问题，首页和列表页怎样把链接交给搜索引擎，同样值得检查。
文章卡片看起来能点，实际不是
首页的文章卡片一直有完整的卡片样式，手机上点击卡片也能进入正文。我直到用电脑操作时才发现，桌面端点卡片没有反应，只有右下角的“查看正文”可以打开文章。
问题藏在实现里。整卡跳转依赖客户端点击逻辑，而且只在手机宽度下启用；文章标题本身不是链接。对普通读者来说，同一种卡片在手机和电脑上的行为不一致。对只分析 HTML 链接的抓取工具来说，每篇文章最明确的入口都是同一句“查看正文”，标题反而没有 <a href> 语义。
我最后没有在“整卡可点击”和“保留文字入口”之间二选一。现在文章标题本身是真实链接，链接文本就是文章标题，并通过覆盖层把点击范围扩展到整张卡片。这样不依赖脚本模拟跳转，键盘操作、在新标签页打开和浏览器原生链接行为也都还在。分类与标签仍是独立链接，不会被整卡入口盖住。
“查看正文 →”也保留了下来。整张卡片能点，不代表每个人都能立刻看出来。这个文字入口负责告诉读者这里可以继续阅读；描述链接内容的工作则交给文章标题。它的无障碍名称还会带上对应标题，但我不会把这一点当成搜索排名技巧，真正清楚的锚文本仍然是标题链接。
分页能翻，不等于文章容易被发现
另一个问题是文章分页。以前主要依赖“上一页”和“下一页”逐页前进，理论上可以从第一页走到最后一页，实际却让较老文章离首页越来越远。现在桌面端会显示首尾页、当前页和附近页码，每个页码都是普通链接。搜索引擎和读者都不必连续翻十几次才能接近后面的文章。
手机端没有照搬一整排页码。小屏幕上塞入十几个数字，只会得到一堆很小又容易点错的按钮。移动端继续使用尺寸足够的上一页和下一页，中间显示当前页、总页数和文章数。列表页仍然保持 noindex, follow：我不希望分页页面占据搜索结果，但希望抓取工具能沿着其中的文章链接继续发现正文。
文章详情页的上一篇、下一篇也顺手纠正了方向。上一篇现在指向更新的一篇，下一篇指向更老的一篇。这主要是阅读顺序和文字含义的问题，内部链接本来就存在，我不期待它单独改变索引量。
这次先观察，不提前宣布有效
到现在我对网站的索引量依旧不放心。之前的检查证明公开文章可以访问，有 canonical、H1，也允许索引；这次又修掉了首页卡片和分页中的链接问题。两组事实可以同时成立：网站没有一个明显的全站拦截错误，但文章发现路径仍然可能做得不够好。
接下来我会分开观察百度和 Google。百度普通收录 API 只影响百度的网址提交，不能拿它解释 Google 的变化。我更关心的是自然抓取能否覆盖新文章和较老文章、已发现但未收录的数量是否下降，以及后续发布是否还必须依赖手动提交才有反应。
如果索引量继续不动，这次修改也不能算解决了问题。至少现在首页交给读者和爬虫的是普通、可描述、能连续遍历的链接，而不是一套只能在特定屏幕宽度下成立的点击效果。先部署，再看数据。
总结
本文讨论搜索引擎优化(SEO)探究个人建站在搜索引擎优化方面的一些问题, 参考搜索文档谈谈我自己对网站搜索优化的一些见解. 在过程中学习site,robots,meta noindex 相关技巧对网站进行配置. 之前我安装过 Yoast SEO, All in One SEO 等插件我觉得好像似乎这些插件把 SEO 这个问题给搞复杂了在文档中 Google 也讨论过这个问题. 搜索引擎优化也有它比较适合匹配的点. 但是在小型建站中个人觉得没必要使用那么复杂的优化手段, 比如 在SEO插件中非常看重的关键字标签也就是页面中的 meta keywords 节点, 在搜索引擎的文档中明确说明了只读取标题以及meta description 描述,keywords是毫无作用的.
当然以上只是我个人看法, 也只是参考了一些文档提出一些见解. 刚开始建立网站对于搜索引擎的优化我依旧在学习阶段. 这篇文章我会慢慢更新总结. 本站优化搜索总的目的只有一个要是别人能在搜索引擎上很快的搜索到我的解决方案, 那么愿一切从未如此简单有趣.😸