企业官网建设流程全解析

1. 先搞清楚：百度到底是怎么收录你的 Hexo 博客的

1.1 搜索引擎收录的两条路径

很多朋友把 Hexo 博客部署上线之后，第一件事就是去百度搜自己域名的关键字，结果翻了好几页都看不到自己的文章，心里凉了半截。其实这不代表你的内容有问题，而是你根本没有给百度“指路”——搜索引擎要收录一个网站，无外乎两条路径：一条是蜘蛛主动顺着链接爬过来，一条是站长主动把网址交上去。

路径一叫“被动抓取”。百度蜘蛛通过外链、导航站、友链等入口找到你的站点，然后顺着页面里的链接一层层翻下去。路径二叫“主动提交”，也就是把你想让搜索引擎收录的 URL 列表直接提交给百度。对于刚上线、外链几乎为零的个人博客来说，被动抓取可能要等很久，而主动提交几乎是立竿见影的。

这正是“百度主动推送”存在的意义。它和 sitemap（站点地图）不同：sitemap 是放在你网站上的一个清单文件，方便蜘蛛来了之后按图索骥；主动推送则是把最新发布的文章 URL 直接“塞到”百度的接收接口里，告诉它“我有新内容了，快来抓”。两者配合，才是完整的收录方案，这也是我当初搭博客踩了一圈坑之后总结出来的结论。

1.2 sitemap 在中间起什么作用

你可以把 sitemap 理解成一份餐厅菜单。蜘蛛进到你的网站（餐厅）之后，顺着菜单点菜，想吃什么就直接翻到哪一页，不用满屋子乱跑。如果连菜单都没有，蜘蛛只能一间间包厢推门进去找，效率低、体力消耗大，收录速度自然慢。

Hexo 默认不会生成 sitemap，需要装插件。常见的做法是生成两个文件：一个是通用格式的sitemap.xml，给 Google、Bing 这些国外搜索引擎用；另一个是baidusitemap.xml，它是百度特有的格式，字段更靠近百度对页面优先级、更新频率的解析习惯。

这里有个很多人忽略的细节：sitemap 里的 URL 地址必须和页面真实可访问的地址一字不差，包括协议（http/https）、域名（带不带www）、结尾斜杠。我的一个学员之前把 Hexo 配置文件里的url写成http://localhost:4000就部署了，生成的 sitemap 里全是 localhost 链接，百度拿到这种列表自然一无所获。后面我会专门讲这个坑。

1.3 为什么很多人部署后久久不收录

说句实在话，百度对个人新站的态度一向比较保守。域名注册时间短、没有备案、服务器在境外、页面更新频率低、外链少，这些因素都会让收录周期拉长。谷歌那边可能文章发出去第二天就搜得到了，百度这边一周都没动静，是非常正常的现象。

但“正常”不代表“没办法”。除了被动等待，你能做的有三件事：第一，在百度搜索资源平台完成站点验证；第二，生成 sitemap 并提交；第三，每次发布文章后执行主动推送。这三件事做完，百度蜘蛛大概率会在几小时到几天内来抓一次，比干等强得多。

2. 站点地图生成：插件选型与一个容易踩的“URL 前缀”坑

2.1 两个常用插件的区别与选择

Hexo 社区里有两个主流插件，分别是hexo-generator-sitemap和hexo-generator-baidu-sitemap。很多人以为装一个就够了，实际我强烈建议两个都装。

hexo-generator-sitemap生成的是标准协议格式的sitemap.xml，结构简单，各大搜索引擎都认识。hexo-generator-baidu-sitemap生成的是baidusitemap.xml，它在标准格式基础上增加了百度能识别的标签属性，比如<locs>这样的节点，更贴合百度的抓取习惯。

两个插件装好后会在public目录下各生成一个 XML 文件，互不干扰。之后你再把两个地址分别提交到百度搜索资源平台的“sitemap 提交”入口，以及 Google Search Console 里，就齐活了。注意：不要只提交 Google 能用的那个，百度对baidusitemap.xml的友好度明显更高。

2.2 安装配置与生成验证

安装命令很简单：

npm install hexo-generator-sitemap --save npm install hexo-generator-baidu-sitemap --save

装完之后重点检查 Hexo 根目录的_config.yml里这几个字段：

url: https://yourname.github.io root: /

url必须填写部署后的完整域名，不要带任何子路径，更不要写 localhost。root一般是/，如果你的博客是放在username.github.io/hexo这种子目录下的，才需要改成对应路径。

然后在_config.yml末尾追加：

sitemap: path: sitemap.xml baidusitemap: path: baidusitemap.xml

保存后执行：

hexo clean hexo generate

去public目录确认是否生成了这两个 XML 文件。我习惯再打开其中一个看看，里面<loc>标签里的地址是否都是你的正式域名。这一步花不了两分钟，但能避免部署完才发现一堆错误链接。

2.3 多语言站点的 sitemap 处理

我遇到过用hexo-generator-i18n或者类似多语言插件的朋友，他们问我：多语言站点的 sitemap 是不是要自己手动去重？其实不用。上面这两个插件在生成时会把所有语言版本的文章 URL 都列出来，因为每个语言版本在 Hexo 里本质上是一篇独立的 HTML 文件。

但这里有一个实操要点：sitemap 里的 URL 必须是能直接访问的地址。如果你的多语言文章路径是/en/xxx/、/zh/xxx/这种，那没问题；如果插件生成的是带?lang=en这种查询参数的地址，建议你在主题配置里把语言切换改成路径式路由，爬虫对带参数的 URL 抓取优先级很低，别指望它自己乖乖去“整理”这些链接。

3. 百度主动推送：从申请到跑通的完整路径

3.1 在百度搜索资源平台完成站点验证

主动推送的第一步，是先证明“这个域名是你的”。你需要去百度搜索资源平台（ziyuan.baidu.com）注册账号，然后添加站点。添加时会让你选验证方式，我用得最顺的是文件验证。

文件验证的操作是：平台会生成一个特定文件名的文件，比如baidu_verify_xxxxx.html，你把这个文件原封不动放进 Hexo 的source目录，然后执行hexo g && hexo d部署上去。等平台那边能通过https://你的域名/文件名访问到这个文件，验证就通过了。

这里有两个提醒：一是文件名里的字符大小写、下划线都要保持原样，部署完先自己在浏览器里访问一遍确认能打开；二是不要放在source/js或source/css之类子目录里，直接放source根目录下，这样生成后会出现在站点根路径。有人因为多放了一层目录，导致验证文件访问 404，来回折腾了一下午。

3.2 主动推送的三种落地方式怎么选

验证通过之后，进入“普通收录 — 主动推送”页面，你会看到一个推送接口地址，格式大致是：

http://data.zz.baidu.com/urls?site=你的域名&token=一串token

这个接口支持 POST 一个纯文本内容，每行一个 URL。有三种落地方式：

• 方式一：后台手动粘贴。适合站点刚建好、文章还不多的时候，直接把 10 来个 URL 粘进去提交，先测试收录效果。
• 方式二：curl 命令。适合偶尔手动补推。我在正文里贴过 curl 示例，一行命令就能推一批。
• 方式三：脚本批量推送。适合把推送动作固化成自动化流程，每次hexo d之后自动执行。这是我目前主力使用的方式，下面详细讲。

如果你只是想快速测试，curl 就已经够用了：

curl -H 'Content-Type:text/plain' --data-binary @urls.txt \ "http://data.zz.baidu.com/urls?site=yourname.github.io&token=你的token"

提前把要推的 URL 写进urls.txt，一行一个，最后一行要以换行结尾。

3.3 自定义推送脚本的完整实现

更多场景下，我建议写一个简单的 Node.js 脚本，放在 Hexo 根目录下，每次生成完站点后自动扫描public目录里的所有.html文件，拼成完整 URL，再批量 POST 给百度。好处是以后每次写文章都不用手动去整理链接。

脚本逻辑大致如下：

const https = require('https'); const http = require('http'); const fs = require('fs'); const path = require('path'); const site = 'yourname.github.io'; const token = '这里填你的token'; const publicDir = path.join(__dirname, 'public'); const urls = []; function walk(dir) { const files = fs.readdirSync(dir); files.forEach(file => { const full = path.join(dir, file); if (fs.statSync(full).isDirectory()) { walk(full); } else if (file.endsWith('.html')) { let rel = path.relative(publicDir, full); rel = rel.replace(/\.html$/, ''); if (rel.includes('index')) { rel = rel.split('index')[0]; } urls.push(`https://${site}/${rel}/`); } }); } walk(publicDir); const postData = urls.join('\n') + '\n'; const postUrl = new URL(`http://data.zz.baidu.com/urls?site=${site}&token=${token}`); const req = http.request({ hostname: postUrl.hostname, path: postUrl.pathname + postUrl.search, method: 'POST', headers: { 'Content-Type': 'text/plain', 'Content-Length': Buffer.byteLength(postData) } }, res => { let body = ''; res.on('data', chunk => body += chunk); res.on('end', () => console.log('推送结果:', body)); }); req.on('error', err => console.error('推送失败:', err.message)); req.write(postData); req.end();

跑一下脚本，看到返回的success字段大于 0，说明接口已经接收了。注意到脚本里我用了http模块，因为百度这个接口是 http 协议，用https模块反而会因为证书问题报错。

4. 脚本推送的细节：返回码、限额与定时触发

4.1 推送结果怎么看：status 与 remain 的含义

调用推送接口后，百度会返回一串 JSON，最常见的三种形态是：

{ "remain": 4999980, "success": 5 }

success表示这次成功接收了多少条 URL；remain表示当天剩余的可提交条数。配额是每天早上重新计算的，新站一般几百到几千条不等，个人博客完全够用。

如果推送失败，返回里会有error字段。常见的情况包括：

另外还有两个字段需要留意：not_same_site表示这批 URL 里有不属于当前站点域名的地址，接口默认直接忽略；not_valid表示 URL 格式不合法。看到这两个字段不为 0，第一件事就是去检查脚本拼接 URL 的逻辑，十有八九是文章路径里带了index.html没有处理掉，或者 URL 写成了双斜杠。

4.2 我遇到的推送失败场景与排查过程

第一次做主动推送时，我的返回结果里success一直是 0，error给了 403。排查了半天发现，问题出在site参数上：我在百度平台验证的是带www的域名，推送接口里填的却是没有www的裸域名。后台提示“非本站地址”，但实际上只要你验证的是主域，接口优先认主域；如果验证的是带www的子域，就必须带www。不同账号状态容易混淆，务必去平台“站点设置”里核对一遍再复制。

还有一次推送后百度返回了not_valid，原因是我脚本拼接路径时，把index.html处理后没有补上结尾的/，生成了类似https://site.com/abouthtml这种畸形地址。这里有一个原则：Hexo 生成文章默认是目录形式，最终 URL 是https://site.com/xxx/，所以脚本里要把.html去掉之后补一个斜杠结尾。我在脚本里已经处理了这一点。

最后一种情况有点隐蔽：CDN 加速导致的 URL 跳转。有个朋友给博客挂了一层 CDN，百度抓取时 301 跳转到另一个协议下的地址，返回的not_valid数量忽然变多。解决方法是统一协议并关闭不必要的跳转，让实际访问 URL 与脚本推送 URL 完全一致。

4.3 部署后自动推送的三种触发方案

手动跑脚本终归不是长久之计，我每次写完文章都希望“发布即推送”。两个主流的自动化触发方式，你可以任选：

方案一：修改 npm scripts。在package.json的scripts里把部署命令改成长链：

"scripts": { "deploy": "hexo clean && hexo g && hexo d && node push.js" }

以后每次执行npm run deploy，就会自动完成生成、部署、推送三个动作。这是最直观的方式，本地跑起来省心。

方案二：Git Hook。如果你习惯直接用hexo d部署，可以在.git/hooks/post-commit里追加一行node push.js。但要注意，这个 hook 在你每次git commit时都会触发，如果你只在部署仓库里提交，问题不大；如果是本地源码仓库频繁提交，每条 commit 都推送一遍就没有必要了。

方案三：GitHub Actions。如果你把 Hexo 源码托管在 GitHub 上，配置一个 workflow，在 push 到主分支后自动执行生成、部署到 Pages、再向百度接口发请求。这种方式的好处是彻底解放本地环境，新人照着网上模板改一改就行。不过维护成本略高，个人博客用前两种方案足够了。

5. 配套工程：robots、主题配置与站点数据核对

5.1 robots.txt：别让蜘蛛白跑一趟

网站地图和主动推送都搞定之后，别忘了还有一个小文件会影响收录：robots.txt。Hexo 默认不会生成它，需要你手动在source目录下新建一个。我给自己的博客用的是极简写法：

User-agent: * Allow: / Sitemap: https://yourname.github.io/sitemap.xml

如果你有不想被收录的目录，比如source/lab这种私有测试页面，可以加上Disallow: /lab/。但要注意：不要全局禁止 JS 和 CSS。很多新手照抄网上的“优化配置”，把.js和.css全部 Disallow 了，结果蜘蛛抓取页面时无法解析排版，反而影响收录质量。

5.2 next 主题侧边栏与统计配置

我用的是 Hexo 经典的 Next 主题。虽然全新版的 Next 提供了很多默认组件，但侧边栏信息还是要自己调。为了配合百度 SEO，我在侧边栏里做了两件事：一是加了一个“站点地图”链接，指向/sitemap.xml，既是给访客用的，也是给蜘蛛多留一个入口；二是把百度统计的代码放进了主题配置里。

Next 的侧边栏配置逻辑是在主题的_config.yml里找一个叫menu的区域，像这样追加：

menu: 站点地图: /sitemap.xml || sitemap

如果你了解 Next 主题结构，就会知道菜单项后面的地址支持相对路径，图标名称可以沿用主题自带的 font-awesome 名字。我这里写的|| sitemap就是图标，不填也没关系。至于百度统计，把从平台复制的 js 代码放到_config.yml的baidu_analytics字段即可，新版主题通常已经预留了入口，不需要去改模板文件。

这里顺带说一句：改写侧边栏的时候，不要为了好看把侧边栏做成纯文字堆砌。导航要精简，有明确的入口，这不仅是为了用户体验，也是为了让蜘蛛沿着清晰的链接结构遍历全站。

5.3 sitemap 与页面实际 URL 的一致性核对

最后一步，也是我最想强调的一步：部署完一定要用真实线上地址核对 sitemap。网站地图生成本地看着没问题，部署后有时候会暴露出一些诡异的情况，比如：

• Hexo 配置的url没改，导致生成的链接是localhost，站点部署上去之后 sitemap 全部无法访问；
• 域名的www与裸域名做了跳转，导致 sitemap 里 URL 和线上规范地址不一致；
• 用了某个主题的“绝对路径”配置，给所有 URL 加了子目录前缀，但时代背景是站点根路径，最终拼出来 404。

我每次部署完都会执行一次curl -I查看线上 sitemap 的响应头，确认文件存在且最后一个<url>节点是能正常访问的文章页：

curl -I https://yourname.github.io/sitemap.xml curl -I https://yourname.github.io/某篇文章路径/

这一步看起来笨，但能提前拦截绝大多数收录问题。毕竟 sitemap 里面哪怕有一条 URL 是 404，百度就可能降低对这个文件的信任度，觉得你这个站点链接质量不稳定。一次正式推送之前，先花五分钟验证，值。

最后再分享一个我自己的小习惯：主动推送不是只在新文章发布时才做。每隔一段时间，我会把全站所有文章 URL 重新批量推一次，尤其当主题改版、URL 结构调整之后。百度的索引过期策略比较激进的时期，重推一次能明显加快旧文章“复活”的速度。我的 blog 上线第一周，靠这套 sitemap 加主动推送的流程，一周内就有文章被百度收录，两个月后整站收录率达到了可观的比例。你如果刚把 Hexo 部署完，就照着上面这几步走一遍，等收录结果的过程会踏实很多。