agent-native：以PostgreSQL为行为中心的TypeScript智能体架构
2026/9/27 23:55:59
前言
我手上有 5 个站：一个 40 多万页的词典站、一个 3 万多页的文案站、一个 4 万多页的查询站、一个日历站和一个在线工具站。前四个是"老站"，最后一个工具站是刚上线的。
自以为老站该做的都做了，直到我用一个下午逐项实测（不是凭感觉，是 curl 一个个抓页面看响应），结果被新站狠狠打脸——新站几乎每个基础项都是缺的。这篇文章把我的自查清单和修复脚本全部分享出来，你可以照着把自己的站过一遍。
自查清单（先收藏这张表）
| 检查项 | 检查方法 | 为什么重要 |
|---|---|---|
| title / meta description | 查看源码 | 收录展示的基本盘，description 影响点击率 |
| canonical | 查看源码 | 防重复收录、权重分散 |
| robots.txt | curl /robots.txt | 爬虫的第一份说明书 |
| sitemap | curl /sitemap.xml | 收录效率的倍增器 |
| favicon | curl /favicon.ico | Google 搜索结果直接展示 |
| 结构化数据 JSON-LD | 查看源码搜ld+json | 富摘要、面包屑展示 |
| HTTP/2 + gzip | curl -sI | 爬虫抓取预算和用户体验 |
| 静态资源缓存 | curl -sI看缓存头 | 老访客二次访问速度 |
| 404 行为 | 访问不存在的路径 | 返回软 404 会污染收录 |
下面按"翻车程度"排序讲。
坑一：favicon 没配——搜索结果里的灰色地球
这是我损失最直观的一项。Google 搜索结果每条前面会显示站点图标，没有 favicon 的站显示一个灰色地球占位符。同样的排名位置，有图标的条目点击率明显更高。
自查：
curl-o/dev/null-w"%{http_code}"https://yoursite.com/favicon.ico# 404 = 没配；再看首页源码有没有 <link rel="icon" ...>修复两步：放一个真实的.ico文件到站点根目录；首页<head>里加<link rel="icon" href="/favicon.ico">。
注意：Google 的站点图标爬虫不是实时的，改完等几天到两周生效。另外.ico文件别随便拿一张 PNG 改后缀，要用真 ICO 格式（网上生成器很多）。
坑二：robots.txt 404
curl https://yoursite.com/robots.txt返回 404。影响有两层：爬虫抓不到你的"抓取规则"；更重要的是robots.txt 是声明 sitemap 位置的官方通道（Sitemap: https://.../sitemap.xml）。
即使你的站没有要屏蔽的路径，也建议放一个最小配置：
User-agent: * Allow: / Sitemap: https://yoursite.com/sitemap.xml如果你的站是 Node/PHP 动态渲染，直接在代码里加个路由返回这段文本，比放静态文件还好维护。
坑三：sitemap 没有，或者只有"半个"
工具站上线时压根没有 sitemap。我的做法是在 server.js 里加一个动态路由，扫描工具目录自动生成：
elseif(p==="/sitemap.xml"){consturls=fs.readdirSync(path.join(__dirname,"tools")).filter(f=>f.endsWith(".html")).map(f=>`https://${HOST}/tools/${f}`);constxml=`<?xml version="1.0" encoding="UTF-8"?> <urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">${[`https://${HOST}/`,...urls].map(u=>`<url><loc>${u}</loc></url>`).join("\n")}</urlset>`;res.writeHead(200,{"Content-Type":"application/xml; charset=utf-8"});returnres.end(xml);}动态生成的最大好处：新增页面自动进 sitemap，永远不会忘。大站（几万页以上）记得用 sitemap index 分片，单文件 5 万条 URL 上限。
坑四：详情页没有 meta description
新站的 100 多个工具页只有 title 没有 description。好消息是每个工具的介绍文案本来就在数据文件里（desc字段），写了个脚本批量注入，一分钟跑完 100 个页面：
// 核心逻辑：读数据文件里的 desc，插到 <head> 后constdata=require("./tools-data.js");for(consttoolofdata.tools){lethtml=fs.readFileSync(`tools/${tool.id}.html`,"utf8");if(html.includes('name="description"'))continue;// 幂等，已注入跳过html=html.replace("<head>",`<head>\n<meta name="description" content="${tool.desc}">`);html=html.replace("</head>",`<link rel="canonical" href="https://host/tools/${tool.id}.html">\n</head>`);fs.writeFileSync(`tools/${tool.id}.html`,html);}两个要点：描述从你已有的真实文案里来（别生成垃圾句式，百度对模板化 description 敏感）；脚本要幂等，重复跑不会注入两次。
坑五：结构化数据缺失
老站都配了，新站没有。最值得配的三种 JSON-LD：
- BreadcrumbList（面包屑）：搜索结果里把丑陋的长 URL 换成
首页 › 分类 › 详情层级路径，层级深的站（我的详情页在最底层）尤其受益 - WebApplication：工具类页面用它有机会触发富摘要
- FAQPage：内容页有明确问答结构的可以上
一个面包屑的示例（可以直接抄）：
<scripttype="application/ld+json">{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"首页","item":"https://example.com/"},{"@type":"ListItem","position":2,"name":"分类名","item":"https://example.com/cat/"},{"@type":"ListItem","position":3,"name":"页面标题"}]}</script>上线后用 Google 的富媒体测试工具（Rich Results Test）验证一遍，JSON 写错一个逗号整段作废。
坑六：静态资源缓存策略混乱
新站所有资源都是Cache-Control: no-cache——每次访问都回源协商。而页面引用资源时都带着版本号（style.css?v=1.5.4），这意味着完全可以放心地强缓存：
- HTML：保持
no-cache+ ETag（内容变了浏览器总能拿到新的） - 带
?v=的静态资源：public, max-age=2592000（30 天）
res.setHeader("Cache-Control",p.startsWith("/assets/")?"public, max-age=2592000":"no-cache");效果是老访客二次打开基本零请求，LCP 直接起飞。前提纪律：改任何静态资源必须换版本号，不然用户会一直用旧缓存。
加分项：把新页面"喂"给搜索引擎
除了被动等抓取，两个主动通道：
- 百度自动推送：页面被访问时向百度提交 URL（一段 JS 搞定）
- IndexNow（必应/Yandex 等）：主动 POST 新 URL 列表，可以做成定时任务每天推一批
对新站来说，"爬虫发现的效率"直接决定收录速度，这两个通道值得都接上。
修复后的效果
修完当天顺手抓了几个页面复验：robots/sitemap/favicon 全 200，106 个页面 description 和 canonical 全覆盖。第三周开始，工具站在百度的收录从个位数涨到了几十页——当然这里面有内容本身的功劳，但基建补齐是前提。
最后一个建议：把这张自查表存下来，每次上新站照着过一遍，半小时能省掉之后几个月的"为什么没收录"焦虑。