一个完全不懂技术的人靠三个看起来很“枯燥”的网站一个月做到二十二万人民币收入——这个标题最近在独立开发和副业圈子里被转了很多次。这个数字本身既没法核实也没什么核实的必要因为这类案例真正值得技术人琢磨的根本不是那个收入数字而是“枯燥”这两个字这三个站的共同点几乎可以肯定是页面结构高度重复、几乎没有交互、内容由数据批量填充、靠搜索引擎的长尾需求吃饭。如果你第一反应是“这不就是采集站、垃圾站”那大概只看到了最外面一层。真正能活过一两年的这类站点靠的从来不是投机的采集而是三件很朴素的事一份别人懒得整理的结构化数据、一套稳定可复现的静态生成流水线、以及长期的收录维护和内容更新。换句话说它更像是一个数据工程问题而不是一个创意问题。这篇文章不讨论怎么快速起量也不推荐任何打擦边球的做法。搜索引擎对批量低质页面的识别能力这几年提升得非常快靠拼接和搬运堆出来的站生命周期往往只有几个月。我们要把它当成一个正经的工程问题来拆数据从哪里来、字段怎么设计、模板怎么保证不重复、静态页面怎么批量生成、sitemap 和结构化数据怎么写、上线之后怎么验证收录、以及最容易被忽略的一点——什么样的页面会被判定成低质。读完之后你应该能做到这样一件事用 Node.js 从一份 JSON 数据出发生成一批结构统一、带 canonical 和 JSON-LD、能被搜索引擎正常索引的静态页面并且清楚这套东西在哪些环节会失败、失败了先看哪里。全文不依赖任何第三方框架脚本只用 Node 内置模块复制下来就能跑。1. 这篇文章真正要解决的问题大部分会写代码的人做副业站点失败的地方往往不在技术而在选题方式。技术人习惯从“我能做什么功能”出发于是去做一个待办清单、一个记账工具、一个 AI 聊天界面——这些方向的问题不是做不出来而是首页之外没有落地的入口用户搜不到你你也拿不到任何一个长尾关键词的位置。“枯燥网站”的思路正好反过来先确认有人在搜再看搜索结果里有没有人认真做。单位换算、邮编查询、节假日安排、行业工具目录、产品参数对比这些需求长年稳定存在搜索量分散在成千上万个长尾词上而供给端经常是一批十年前的页面、一堆广告糊脸的聚合站。供给稀薄加上需求稳定这才是那三个站能赚钱的底层原因。所以这篇文章要解决的核心问题是如何用工程化的方式把一份结构化数据变成一批“每个页面都在回答一个具体问题”的静态页面并且让搜索引擎愿意收录它们。关键词是“工程化”不是写三个页面而是让三百个页面能用一条命令重新生成并且保证每个页面的标题、描述、正文、内链都不重复。适合读这篇文章的人有三类会写脚本、想把技术变成长期资产的开发者正在做独立站、卡在“页面生成完但收录很差”这个阶段的同学以及想完整练一遍“数据清洗、模板渲染、静态部署、监控”链路的工程师——哪怕你最后不做站这条链路在生产项目里也用得上。不适合读的人也有想三天上线、七天变现、不愿意做数据清洗和内容维护的这套方法会让你失望因为它的成本恰恰在“枯燥”那一部分。2. “枯燥网站”的核心概念与技术原理2.1 程序化生成页面到底指什么程序化生成页面Programmatic Page Generation听起来很唬人说白了就是页面不是一个个手写的而是由“数据 模板”批量渲染出来的。你维护一份结构化清单模板负责把每条记录渲染成一个独立 URL 的 HTML 文件标题、描述、正文、结构化数据全部由字段拼出来。没有这套东西的时候做三百个换算页面意味着复制粘贴三百次改一次页头要改三百个文件加一个字段要重做一遍。引入之后流程变成改 JSON → 跑一条构建命令 → 三百个页面重新生成。这里的差别不是效率提升百分之几十而是“这件事能不能持续做下去”的差别。新手最容易误解的一点是以为程序化生成等于“内容自动生成”。恰恰相反程序化生成解决的是排版和结构的重复内容本身必须来自真实的数据和人工整理的说明。用模型批量生成三百篇空话当正文短期可能有收录长期基本都会被清理掉。2.2 三类最典型的“枯燥”站点把标题里那三个站抽象一下绝大多数同类项目都落在下面三类里。它们的共同特征是单页价值不高但很具体用户来了就走不需要登录不需要交互非常适合纯静态。站点类型典型例子数据从哪来技术难点变现方式换算计算类单位换算、汇率、税率、日期计算公开标准、公式、官方口径公式准确性、精度处理展示广告、工具内推荐位目录导航类各城市服务商目录、行业工具清单公开名录、人工整理、用户提交数据去重、真实性审核收录费、广告位、导流对比参数类产品参数对比、套餐对比官方页面、公开文档数据时效、更新机制联盟推广、比价分成这三类的共同工程结构完全一致一份 JSON 数据、一个页面模板、一个构建脚本、一个 sitemap、一套监控。也就是说你做通一类另外两类只是换数据和换模板的事——这才是“一个人能同时维护三个站”的技术前提。2.3 为什么不建议一上来就用重型框架很多人第一步就去装 Next.js 或者某个 CMS结果卡在配置上两周。对于纯静态内容站判断标准很简单页面在构建时就能完全确定运行时不需要查数据库、不需要鉴权、不需要个性化。这种情况下静态站点生成SSG比服务端渲染更合适——产物是纯 HTML可以直接扔到对象存储或者 CDN 后面没有服务器要维护没有进程会挂成本接近于零。维度传统 CMS动态静态生成SSG运行依赖需要 PHP/Java/Node 进程和数据库只需要静态文件托管单页加载每次请求查库渲染直接返回 HTML可全量 CDN 缓存批量改版改模板后需清缓存、逐页验证重跑构建产物可 diff 对比安全面后台、插件、数据库都是攻击面没有后台就没有后台漏洞成本服务器 数据库 运维托管基本免费只付域名和 CDN代价也很明确更新内容要重新构建、构建时间随页面数增长、搜索、评论这类动态能力要额外接第三方。对于一个以内容为主的小站这些代价完全可以接受。3. 技术选型与环境准备3.1 最低可用的环境清单下面这套组合是我认为性价比最高的起步方案除了 Node 之外没有别的必须项运行环境Node.js 20 LTS 及以上示例脚本只用node:fs/promises和node:path不需要安装任何第三方包。版本请以你本机实际环境为准本文重点演示通用思路。包管理与脚本npm只用来跑build命令。版本管理Git构建产物不入库只入库数据和模板。编辑器VS Code 即可建议装一个 JSON 语法校验插件。托管任意静态托管服务能上传目录、能配自定义域名、能开 HTTPS 就行。域名与解析一个短、好记、和主题相关的域名比花哨的后缀重要得多。如果你的目标用户主要在国内托管在境内节点涉及备案等合规要求这一步建议提前规划不要等页面全做完才发现域名用不了。使用境外托管时也要注意访问稳定性否则收录和体验都会受影响。3.2 目录结构先定好工程结构定得早后面加数据、换模板都不会乱。建议从一开始就用下面这个结构dist是构建产物data是唯一的内容来源boring-site/ ├── data/ │ └── length.json ├── scripts/ │ └── build.mjs ├── public/ │ └── robots.txt ├── package.json └── dist/ # 构建产物加入 .gitignore把“数据”和“渲染”彻底分开是这套方案最重要的一条纪律。只要数据是干净的 JSON将来换 Astro、换 Next、换任何模板引擎迁移成本都很低反过来如果一开始就把内容写死在 HTML 里第二次改版就会变成灾难。4. 核心流程拆解从关键词到可收录页面整条链路可以拆成六步每一步都有明确的输入输出也有明确的失败表现。理解这六步比记住任何代码都重要。第一步确定页面清单。输入是一批长尾关键词输出是“要生成哪些 URL”的列表。做法是从搜索下拉词、相关搜索、行业文档目录里去收集然后按语义聚类一个词对应一个页面。失败表现很典型两个页面回答的是同一个问题最后互相竞争排名两边都上不去。第二步整理结构化数据。每个页面至少要有唯一 slug、标题、分类、一句话摘要、核心数值或事实、数据来源、更新时间。这一步是整个项目里最花时间、也最决定成败的部分。数据不准页面做得再漂亮也没人用数据没有来源后面做内容审核时会很被动。第三步设计模板。模板要保证两件事所有页面共享同一套结构和内链每个页面的可见文本有足够差异。差异不是靠多写几句套话而是靠真实数据字段的呈现——单位换算页要显示换算系数和常见对照值对比页要显示参数表格目录页要显示条目属性。这一层做不好页面就会被判定为模板堆砌。第四步批量渲染。脚本读取数据、校验字段、渲染 HTML、写出到dist。校验一定要做而且要“快速失败”slug 重复、标题重复、必填字段缺失都应该让构建直接报错退出而不是生成一堆带问题的页面。第五步输出 sitemap 和 robots。搜索引擎需要一个入口知道自己该抓哪些 URL。sitemap 里带上lastmod能让抓取优先级更合理robots.txt 里声明 sitemap 地址是最省事的提交方式。第六步上线、提交、监控。部署到静态托管绑定域名去搜索引擎的站长平台提交 sitemap然后看收录曲线、索引状态、以及有没有被判定为“已抓取未编入索引”。最后这一项是判断内容质量的直接信号出现大面积“已抓取未编入索引”基本可以确定是内容重复或价值不足。5. 完整可运行的示例代码下面用一个“单位换算”小站做最小示例。选它是因为数据最简单、公式可验证适合先把流程跑通再换成你自己的数据。5.1 数据结构设计[ { slug: cm-to-inch, title: 厘米转英寸, category: length, summary: 1 厘米约等于 0.3937 英寸支持输入任意数值实时换算并给出常见数值对照。, factor: 0.3937007874, updatedAt: 2025-03-01 }, { slug: km-to-mile, title: 千米转英里, category: length, summary: 1 千米约等于 0.6214 英里适用于跑步配速、里程换算等场景。, factor: 0.6213711922, updatedAt: 2025-03-01 } ]文件放在data/length.json。几个字段的设计意图值得说清楚slug是 URL 的唯一标识只用小写字母、数字和连字符避免中文 URL 带来的编码问题category用来生成目录层级和首页分组summary会同时写进meta namedescription和页面首段所以它必须是一句“回答了问题”的话而不是关键词拼接updatedAt决定 sitemap 里的lastmod也告诉用户这条数据新不新。5.2 生成脚本这是整个项目的核心一个文件搞定校验、渲染、首页、sitemap 四件事// 文件路径scripts/build.mjs import { readFile, writeFile, mkdir, readdir } from node:fs/promises; import path from node:path; const ROOT process.cwd(); const DATA_DIR path.join(ROOT, data); const OUT_DIR path.join(ROOT, dist); const SITE_URL (process.env.SITE_URL || https://example.com).replace(/\/$/, ); const SITE_NAME 单位换算小站; const escapeHtml (value ) String(value) .replace(//g, amp;) .replace(//g, lt;) .replace(//g, gt;) .replace(//g, quot;); function assertItem(item, fileName) { for (const key of [slug, title, category, summary, updatedAt]) { if (!item[key] || String(item[key]).trim() ) { throw new Error(数据校验失败${fileName} 缺少字段 ${key}); } } if (!/^[a-z0-9](-[a-z0-9])*$/.test(item.slug)) { throw new Error(数据校验失败${fileName} 的 slug 不合法 - ${item.slug}); } if (!Number.isFinite(Number(item.factor))) { throw new Error(数据校验失败${fileName} 的 factor 不是有效数字); } return item; } function renderPage(item, related) { const canonical ${SITE_URL}/${item.category}/${item.slug}/; const jsonLd { context: https://schema.org, type: WebPage, name: item.title, description: item.summary, url: canonical, dateModified: item.updatedAt }; const relatedHtml related .map((r) lia href/${r.category}/${r.slug}/${escapeHtml(r.title)}/a/li) .join(); return !DOCTYPE html html langzh-CN head meta charsetutf-8 meta nameviewport contentwidthdevice-width, initial-scale1 title${escapeHtml(item.title)} | ${SITE_NAME}/title meta namedescription content${escapeHtml(item.summary)} link relcanonical href${canonical} script typeapplication/ldjson${JSON.stringify(jsonLd)}/script /head body main h1${escapeHtml(item.title)}/h1 p${escapeHtml(item.summary)}/p form idcalc label输入数值 input idvalue typenumber value1 stepany/label button typesubmit换算/button /form p idresult换算结果0.3937/p h2相关换算/h2 ul${relatedHtml}/ul p数据更新时间time datetime${item.updatedAt}${item.updatedAt}/time/p /main script (function () { var factor ${Number(item.factor)}; var form document.getElementById(calc); var input document.getElementById(value); var out document.getElementById(result); form.addEventListener(submit, function (e) { e.preventDefault(); var v Number(input.value); out.textContent 换算结果 (isFinite(v) ? (v * factor).toFixed(4) : 请输入合法数值); }); })(); /script /body /html; } function renderHome(items) { const groups new Map(); for (const item of items) { if (!groups.has(item.category)) groups.set(item.category, []); groups.get(item.category).push(item); } const body [...groups.entries()] .map(([category, list]) { const links list .map((i) lia href/${i.category}/${i.slug}/${escapeHtml(i.title)}/a/li) .join(); return sectionh2${escapeHtml(category)}/h2ul${links}/ul/section; }) .join(); return !DOCTYPE html html langzh-CN head meta charsetutf-8 title${SITE_NAME}/title meta namedescription content按分类整理的单位换算页面当前共 ${items.length} 个。 /head bodymainh1${SITE_NAME}/h1${body}/main/body /html; } function renderSitemap(items) { const urls items .map( (i) urlloc${SITE_URL}/${i.category}/${i.slug}//loclastmod${i.updatedAt}/lastmod/url ) .join(\n); return ?xml version1.0 encodingUTF-8? urlset xmlnshttp://www.sitemaps.org/schemas/sitemap/0.9 ${urls} /urlset; } async function build() { const files (await readdir(DATA_DIR)).filter((f) f.endsWith(.json)); if (files.length 0) throw new Error(data 目录下没有找到 JSON 数据文件); const items []; const seenSlug new Set(); const seenTitle new Set(); for (const file of files) { const raw await readFile(path.join(DATA_DIR, file), utf8); const list JSON.parse(raw); for (const entry of list) { const item assertItem(entry, file); const id ${item.category}/${item.slug}; if (seenSlug.has(id)) throw new Error(slug 重复${id}); if (seenTitle.has(item.title)) throw new Error(标题重复${item.title}); seenSlug.add(id); seenTitle.add(item.title); items.push(item); } } for (const item of items) { const related items .filter((x) x.category item.category x.slug ! item.slug) .slice(0, 6); const dir path.join(OUT_DIR, item.category, item.slug); await mkdir(dir, { recursive: true }); await writeFile(path.join(dir, index.html), renderPage(item, related), utf8); } await writeFile(path.join(OUT_DIR, index.html), renderHome(items), utf8); await writeFile(path.join(OUT_DIR, sitemap.xml), renderSitemap(items), utf8); console.log(构建完成共生成 ${items.length} 个内容页); } build().catch((err) { console.error(err.message); process.exit(1); });几个关键点解释一下。第一escapeHtml一定要有哪怕是全中文内容站用户提交或采集来的数据里出现一个就会破坏页面结构这是最常见的低级事故。第二seenSlug和seenTitle两个集合是防重复的最后一道闸标题重复在搜索侧就是自我竞争宁可构建失败也不要生成。第三related内链只取同分类的前六条既保证每个页面都不是孤岛又不会让页面底部堆出几百个链接。第四换算逻辑放在前端内联脚本里构建时输出的是纯静态 HTML首屏内容不需要 JS 就能读到这对收录很关键。5.3 构建、部署与自动化package.json只需要几行把它当成一个任务入口{ name: boring-site, private: true, type: module, scripts: { build: node scripts/build.mjs, preview: python3 -m http.server 8080 -d dist } }robots.txt放在public/robots.txt最后一行告诉搜索引擎去哪里找地图User-agent: * Allow: / Sitemap: https://example.com/sitemap.xml如果托管支持 Actions 之类的 CI每次推送自动构建部署能省掉手工上传的重复劳动# 文件路径.github/workflows/deploy.yml name: build-and-deploy on: push: branches: [main] workflow_dispatch: permissions: contents: read pages: write id-token: write jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - uses: actions/setup-nodev4 with: node-version: 20 - run: npm run build env: SITE_URL: https://example.com - uses: actions/configure-pagesv5 - uses: actions/upload-pages-artifactv3 with: path: dist deploy: needs: build runs-on: ubuntu-latest environment: name: github-pages steps: - uses: actions/deploy-pagesv4注意SITE_URL是通过环境变量注入的这一点很重要本地用占位域名线上用真实域名canonical 和 sitemap 才不会写错。canonical 写错的后果比很多人想象的严重它会让搜索引擎认为你的页面指向了另一个不存在的地址。6. 运行结果与效果验证本地跑一遍先确认产物结构对SITE_URLhttps://example.com npm run build预期输出构建完成共生成 2 个内容页然后看目录两个页面加首页加 sitemap一共五个文件find dist -type f | sortdist/index.html dist/length/cm-to-inch/index.html dist/length/km-to-mile/index.html dist/sitemap.xml起个本地服务看效果用 Python 自带的静态服务器最省事python3 -m http.server 8080 -d dist打开http://localhost:8080/length/cm-to-inch/页面上应该能看到三级标题、摘要、输入框、相关换算列表和更新时间。输入 10 点换算结果应该是3.9370。再做几项命令行校验比肉眼翻页面可靠得多curl -s http://localhost:8080/length/cm-to-inch/ | grep -o link relcanonical[^]* curl -s http://localhost:8080/sitemap.xml | grep -c url curl -s http://localhost:8080/length/cm-to-inch/ | grep -o type:[^]*第一行应该输出带完整 URL 的 canonical 标签第二行数字要和页面数一致第三行应该看到WebPage。如果第二行数字对不上说明有的页面没进 sitemap通常是分类目录写错导致的路径不一致。上线之后验证分三层看。第一层是可达性curl -I看状态码确认返回 200 而不是 301 到别处也不是 404。第二层是收录在站长平台提交 sitemap等一到两周看“已收录”和“已抓取未编入索引”的比例。第三层是体验用 Lighthouse 或者 Pagespeed 跑一遍静态页面通常能轻松拿到很高的分数如果不行八成是图片没压缩或者字体加载阻塞了首屏。判断这套流程是否成功最直接的信号不是流量而是“已抓取未编入索引”的比例。这个指标高说明搜索引擎抓到了但不认可问题一定在内容层面不在技术层面。7. 常见问题与排查思路问题现象可能原因排查方式解决方案构建直接报错退出数据缺字段、slug 含大写或空格、标题重复看报错信息里的文件名和字段名修正 JSONslug 统一小写连字符页面能打开但样式全丢引用的是绝对路径且域名没配浏览器控制台看 404 资源静态资源改用相对路径或统一 CDN 域名sitemap 里有 URL但线上 404输出的目录层级和 sitemap 拼的路径不一致对比dist实际目录和 sitemap 里的 loc把路径拼接抽成一个函数两处共用一个来源大量“已抓取未编入索引”页面之间文本高度雷同只是换了个词随机抽十个页面去掉标题对比正文补充真实数据字段增加对照表、说明、来源canonical 指向错误域名构建时没注入SITE_URLcurl抓页面看 canonical 标签CI 里显式传环境变量本地用占位域名页面数到几百后构建变慢每页都做全量数据过滤在脚本里加计时日志先按分类建索引 Map避免嵌套遍历首页打不开但子页面正常首页只在构建末尾生成中途报错被中断看构建日志是否跑完最后一步先清理dist再全量构建避免残留旧文件提交 sitemap 后一直显示“无法抓取”站点有访问限制、 robots 屏蔽、或域名解析未生效用curl从外网访问 sitemap检查 robots.txt、DNS、HTTPS 证书状态补充两个不在表里但很常见的坑。一个是编码问题JSON 文件必须存成 UTF-8Windows 下用记事本另存容易带上 BOM导致JSON.parse直接抛错报错信息还很难懂。另一个是时间格式lastmod必须是YYYY-MM-DD这种标准格式写成中文日期会让整个 sitemap 校验失败而这种失败在站长平台里往往只显示一句“格式错误”。8. 最佳实践别把“批量”做成“垃圾”这块是整篇文章最想强调的部分。程序化生成是一把双刃剑用得好是效率工具用不好就是批量制造低质页面最后被整站降权。第一条一个页面只回答一个问题。判断标准很朴素把标题遮住只看正文读者能不能知道自己该做什么。如果两个页面的正文除了名词之外几乎一样就必须合并成一个页面或者给它们补充不同的实质内容。数量从来不是护城河覆盖质量才是。第二条数据来源必须可追溯。每个数据文件里保留来源字段页面上标注更新时间和数据口径。这不只是为了显得专业更是为了在出现争议时有据可查。涉及汇率、税率、政策口径这类会变动的数据一定要有明确的“以官方为准”提示并且设置定期复核。第三条构建过程要可重复、可回滚。构建脚本里不要有随机数、不要有当前时间戳直接进页面会污染 diff数据和模板都进 Git产物不入库。这样任何一次改版都能通过回滚 commit 恢复出问题时不用手忙脚乱。第四条把索引当产品指标来监控。每周看三个数提交的 URL 数、已收录数、有展现的关键词数。前两个数差距持续扩大说明内容质量有问题第三个数长期不涨说明选词方向有问题。这两个问题都不是改代码能解决的越早发现越省事。第五条合规问题提前处理。境内托管涉及备案、页面涉及用户信息收集要有隐私说明、有广告位要区分清楚广告和内容、做联盟推广要按要求披露利益关系。目录类站点如果收录第三方信息要注意信息来源的合法性和被收录方的意愿避免不必要的纠纷。变现这块急不得先把内容和收录做扎实。第六条控制成本别过度工程化。一个几百页的静态站纯静态托管加上 CDN 的费用几乎可以忽略真正的时间成本在数据整理和内容维护。不要一开始就上数据库、上搜索服务、上边缘函数等到页面数过万、或者确实需要站内搜索时再考虑。过早引入复杂度最后往往是自己维护不动。9. 写在最后先跑通一百个页面回到开头那个标题。三个“枯燥”的网站能做到那个量级可以确定的是它背后一定有一套能低成本持续产出页面的机制否则一个人根本维护不过来三个站。这套机制的技术含量并不高难的是数据整理、内容判断和长期坚持而这些恰恰是“会写代码”帮不上忙的部分。这篇文章讲清楚的事情其实就三件第一这类站点的技术本质是“结构化数据加模板批量渲染成静态页面”跟 AI、跟复杂架构都没关系第二整条链路有明确的六个环节每个环节都有对应的失败表现能定位就能修第三程序化生成的红线是内容重复页面的价值必须来自数据和说明而不是模板套话。接下来建议的实践路径是这样先做一个小到不可能失败的版本一百个页面以内一个分类数据你自己能手核一遍。跑通构建、部署、提交 sitemap、观察收录这条完整链路看看“已抓取未编入索引”的比例。如果这一百个页面能被正常收录再考虑扩到一千个如果一百个都收不进去扩到一万个只会让问题放大。一个实用的小技巧把每次改版的构建产物做一次 diff 对比只关注title、h1和meta description这三处有没有意外变化。静态生成最大的风险不是生成失败而是“悄悄生成错了却没人发现”一个三行的 diff 检查脚本比任何监控都来得直接。