个人网站上线后，怎样获取流量、统计访问，并展示每篇阅读量？

网站上线后，我想弄清楚三件事：Google 能不能找到它，有没有人进来看，以及每篇文章到底被打开了多少次。

这次整理申屠手记时，我先检查了搜索收录，再接上文章阅读量。2026 年 10 月 12 日，阅读计数接口上线，随后一篇文章的返回值从 0 变成了 1。这个很小的变化，意味着网站终于有了一条可以核对的记录。

下面按这次实际做过的流程展开。搜索检查和计数接入有操作记录；获取流量部分是一套可以开始执行、继续观察效果的方案。后台访问分析另附官方配置步骤，尚未拿到本站完整的来源报表。

适用范围：已经上线、有独立域名、使用 Cloudflare Pages 托管的静态网站。 静态网站可以理解为：文章主要是 HTML 文件，通常没有自己的数据库。WordPress 用户可以先用现成统计插件；其他托管平台可以参考思路，但域名路由和发布方式要调整。

可以分三次完成：先做搜索检查，再接后台统计，最后接阅读量。后半部分需要编辑网站文件和使用终端；建议先选一篇文章走通，再接入其他文章。

你会得到三个结果：搜索收录检查的方法、一套查看访问来源的后台，以及文章入口和正文里的“阅读 0、阅读 1……”数字。

一、先想清楚：我要看哪一种数字？

Cloudflare 的域名概览会展示请求等数据，图片、脚本和爬虫访问也可能出现在其中。要知道某篇文章的表现，需要具体到页面的统计口径。

我的做法是：后台分析留给自己看，文章阅读量展示给读者看。两边各有用途，也会出现不同的数字。

这篇教程里的“阅读量”定义为：允许统计的文章，在可见的浏览器页面中打开后，成功记录一次访问；同一标签页会话内，同一文章 30 分钟内重复打开去重。 它不判断读者是否读完，也不等于独立人数。切换设备、浏览器或新会话可能再次计数。

二、获取流量：先让页面被找到，再给读者一个点进来的理由

第 1 步：检查首页和文章入口

先用普通浏览器打开首页，按导航找到一篇文章。确认标题能点开、图片能显示、手机上能阅读。从首页或栏目页到文章，应当有正常的文字链接。

给每篇文章一个具体标题。例如“工具使用心得”很难判断有没有用；“把当天照片和一句话存进日记：Daily You 怎么用”更容易让需要它的人做决定。开头直接交代解决的问题和结果，再展开步骤。

这些是每篇文章上线前的基本检查。只有图片或一块需要执行脚本才能出现的内容时，还要检查 Google 能否看到页面正文。

第 2 步：在 Search Console 检查收录

打开 Google Search Console，选择你的网站资源。首次使用时先添加资源并按页面提示验证所有权；域名资源通常需要到 DNS 添加 Google 给出的 TXT 记录。已有资源就继续使用它，不必为了本文再建一份。

随后按顺序操作：

1. 复制一篇文章的完整正式地址，如 https://example.com/articles/hello/。
2. 粘贴进顶部的 URL 检查输入框，按回车。
3. 看结果是 URL is on Google（已在 Google 上）还是 URL is not on Google（尚未收录）。
4. 未收录时展开 Page indexing，先读原因；再点 TEST LIVE URL，检查当前页面是否可访问。
5. 实时测试通过后，点结果卡右下角的 REQUEST INDEXING。
6. 出现 Indexing requested，这一步就完成了。

图 1：本站游戏页的真实检查结果。绿色对勾表示当前页面可供 Google 访问，右下角才是请求索引入口。

图 2：出现这个提示后，等待 Google 后续处理即可。提交请求不保证收录，反复提交也不会提高排队优先级。

如果显示 404，先核对地址。如果文章确实已经撤下，保留正确的 404 状态；如果本来应该上线，就修复文件或链接后再测。若显示“已发现，尚未编入索引”，说明 Google 已知道地址，还不能由此判定文章质量有问题。

本站当时的报告中，未收录地址还包括已经撤下的文章和 RSS 文件。我没有把它们全部当成必须恢复的内容。具体检查方法可对照 Google 的重新抓取说明。

第 3 步：提交站点地图

站点地图是一份公开的网址清单，常用地址是 https://你的域名/sitemap.xml。

先在浏览器打开它，确认里面列的是正式文章地址。再进入 Search Console 左侧 Sitemaps，填写 sitemap.xml 并提交。若资源界面没有自动显示域名前缀，就填完整地址。

图 3：本站 sitemap 提交成功。报告里的“发现页面数”表示从地图发现的网址数量，不表示这些页面都已收录。

以后增加文章，要让网站构建程序一起更新这份清单。提交完某篇文章，再忘了把它放入栏目和地图，后续维护就容易断开。

第 4 步：只选一个外部渠道做第一轮实验

开始时，我建议只选一个自己熟悉的平台，找与文章内容直接相关的人。先按社区规则写清有用的结论，在允许链接的地方附上文章地址。需要审核的平台先提交草稿；禁止推广的社区就只参与讨论。

一次可以这样做：

• 选一篇解决具体问题的文章。
• 写一段“遇到了什么问题、试了什么方法、读者能拿走什么”的短分享。
• 发布前记录日期、平台和文章地址。
• 接下来七天，查看该文章的来源访问与 Google 搜索点击。
• 有人提问就把问题记下来，优先补充这篇文章。

分享可以从这样一段话开始，再按平台规则调整：

个人网站上线后，我想知道每篇文章被打开了多少次。这次用 Cloudflare Worker 和 D1 接了一个小计数器：列表能看数字，同一标签页 30 分钟内重复打开会去重。我把建库、部署、网页接入和报错排查整理成了教程，适合已经用 Pages 建站的人。

这是一份分享草稿，尚未验证它能带来多少访问。允许放链接时，在末尾附正式文章地址；不允许推广的地方不发这段推广内容。

用一张表记下结果，第一轮就能看出哪些环节缺证据：

这里的七天是自己安排的观察窗口，不是搜索收录的承诺时间。来源可能被浏览器或平台隐藏，所以记录中允许出现“直接访问／来源未知”。

不要靠自己反复刷新验证增长。这个网站的流量增长效果仍需继续观察；接好统计后，才能用真实变化评估哪一种分享值得继续。

三、统计访问：先给自己接一个后台

如果你也用 Cloudflare Pages，可以先启用 Web Analytics。这一步与后面显示阅读数字的计数器分别配置。

按 Cloudflare 官方说明：

1. 进入 Workers & Pages，点开托管网站的 Pages 项目。本站是 shentunotes。
2. 打开 Metrics，在 Web Analytics 区域选择 Enable。
3. 重新部署一次网站，分析脚本会在下一次部署时加入。
4. 打开自己的正式网站，正常浏览一两个页面，再回到报表查看。

页面或菜单名称若调整，可直接用后台搜索寻找 Web Analytics。已经启用的站点先检查现有配置，避免再手动装一份相同脚本。

第一次看报表，只回答两个问题：这周哪些文章有人访问？访问主要来自哪里？ 选择日期范围，再查看路径（Path）和来源（Referer）。这些维度见 官方字段说明。

本节是按官方文档整理的接入方法；我这次已验证的是下文的阅读计数链路，尚无本站 Web Analytics 来源报表截图可作为效果证明。报表没出现数据时，先检查是否已重新部署、页面是否加载分析脚本，以及浏览器是否拦截它。

四、展示每篇阅读量：选择一个能够持续保存数字的方案

只有浏览器里的 JavaScript，无法替全站读者保存共同的累计数字。我这次用了三个部分：

文章页面 → 计数接口（Worker）→ 保存数字的数据库（D1）→ 把数字显示回页面。

可以这样理解：网页负责报告“这篇文章被打开了”，Worker 负责检查请求并记账，D1 负责保存账本。读者在列表上看到的数字，也是网页向同一个接口查询的结果。

本文提供一份可下载的入门代码包。它从本站方案整理而来，使用显式标记选择显示位置，方便放到不同网站模板中。示例经过本地逻辑检查；你的域名、文章路径和网站模板仍要按后面的步骤替换并验收。

第 5 步：准备材料，认清两个项目

准备一个已有的 Cloudflare Pages 网站、它的自定义域名、可登录的 Cloudflare 账号，以及能编辑和重新发布网站的电脑。自定义域名应已接入 Cloudflare，并有代理状态正常的 DNS 记录。本文以 Mac 终端演示。

你会接触两个不同的名字：

• Pages 项目：原有网站，保留你现在的项目名。
• Worker：新建的计数接口，示例取名 website-readership。

域名下只有 /api/readership 这一条接口交给 Worker。文章和首页继续由原网站提供。

先保存当前成功发布的网站包。解压入门代码包，得到 readership-starter 文件夹。它不是完整网站，不要把它直接当作整站上传到 Pages。

readership-starter/
  counter/
    worker.js          接口程序
    pages.json         允许计数的文章地址
    schema.sql         数据库建表语句
    wrangler.jsonc     部署配置
  site-assets/
    readership.js      在网页显示和记录数字
  README.md

第 6 步：创建 D1 数据库

在 Cloudflare 后台搜索 D1，进入 D1 SQL Database，创建一个数据库，名字填写 website-readership。保存后打开数据库详情。

图 4：本站使用的 D1 数据库。教程里的名称可自定，但后面的配置需要一致；请按自己的数据库详情复制标识。

进入 Console，用文本编辑器打开代码包中的 counter/schema.sql，复制全部内容粘贴到输入框，再点 Execute。

图 5：看到 This query successfully executed，说明建表步骤完成。复制时包含末尾的触发器，不能只复制第一句。

这段 SQL 建立两张表：counts 每个“事件类型＋文章路径”保存一个累计数；events 每条记录保存一次带随机编号的请求。相同编号重复到达时只记一次，成功新增事件时由触发器更新累计数。

无需手动填入一个好看的初始值。没有历史统计的新站，从 0 开始即可。

第 7 步：修改三个文件

用 VS Code 等纯文本编辑器打开代码包。先修改 counter/wrangler.jsonc：

• routes 中的 example.com 改成自己的正式域名，保留 /api/readership*。
• zone_name 改成 Cloudflare 中对应的网站区域名称。若网站用 www.example.com，路由写 www.example.com/api/readership*，区域通常仍是 example.com。
• database_id 填入刚创建的 D1 数据库 UUID；从详情页复制。
• database_name 与刚才创建的名称一致。
• name 是 Worker 的名字，不要填原 Pages 项目名。
• ratelimits 中的 namespace_id 示例为 1001。若账号内已有其他限流器，请给本计数器使用一个未占用的正整数编号，避免共用限流空间。

随后打开 counter/worker.js，把最上面的地址改为自己的正式网站来源：

const ORIGIN='https://example.com';

这个地址要与浏览器访问时一致，包括是否带 www，末尾不要加斜杠。

最后编辑 counter/pages.json，填入你已公开的文章路径。路径从域名后面的 / 开始，保留结尾的斜杠：

{
  "read": [
    "/articles/hello/",
    "/articles/another-post/"
  ],
  "start": []
}

start 留空即可，这篇只接文章阅读量。路径照浏览器地址填写，不要把文章标题、完整网址或本地文件路径填进去。最后一项后面没有逗号。

第 8 步：登录并部署计数 Worker

先从 Node.js 官网安装当前受支持的 LTS 版本。重新打开 Mac 的“终端”，输入下面两行，能看到版本号就可以继续：

node -v
npm -v

在终端输入 cd（后面有一个空格），把刚解压的 readership-starter 文件夹拖入窗口，再按回车。这样不必自己手写很长的本地路径。

执行：

npx wrangler@4.149.0 login

如果提示安装，输入 y 并回车；浏览器打开后，检查登录的是你的 Cloudflare 账号，完成授权，再回到终端。本文实测使用 Wrangler 4.149.0；后续版本要求以 官方安装说明为准。

接着执行：

npx wrangler@4.149.0 deploy --config counter/wrangler.jsonc

图 6：验收时看 DB、LIMITER、Uploaded 和 Deployed ... triggers。图中是本站实际部署输出，项目名与你的可以不同。

配置文件会一起部署 D1 绑定、限流、接口路由和定时清理。当前示例每个 IP 在一个 Cloudflare 节点限流窗口内最多请求 30 次／60 秒；共享网络下的不同人可能共用 IP。它主要用于减少异常重复写入，不能保证完全防刷。官方还说明这类限流是按节点、最终一致的，见 Rate Limiting。

0 3 * * * 是每天 UTC 03:00、北京时间 11:00 清理超过七天的事件明细。累计数保留，不会每天归零。

第 9 步：先验证接口，再改网页

部署完成后，到 Worker 的 Domains 或 Settings → Domains & Routes 查看路由，应该是：

你的域名/api/readership*

图 7：路由只匹配计数接口。保留 /api/readership*，不要扩大成整个网站的 /*。

浏览器直接打开 https://你的域名/api/readership，通常会返回 {}。这个空对象说明接口能响应空查询，还没有验证数据库中的文章查询。

再打开下面的地址：把 example.com 换成自己的域名，把 hello 换成刚写入清单的文章路径，其他结构保持不变。也可以使用代码包 README 里的查询示例。

https://example.com/api/readership?items=[{"kind":"read","path":"/articles/hello/"}]

浏览器会处理地址中的特殊字符。新文章正常返回：

{"read:/articles/hello/":0}

图 8：本站正式域名接口返回具体文章的 0，表明路由和数据库读取都已接通。

如果出现 invalid pages，检查文章路径是否在 pages.json 中，并确认修改后重新部署过 Worker。返回 503 时先核对 D1 的 DB 绑定和建表状态。这里通过后再继续，排错会简单很多。

第 10 步：把数字放在文章入口和正文

把代码包里的 site-assets/readership.js 复制到你网站的公开资源目录，发布后应能从 /assets/readership.js 访问。例如最终发布目录叫 dist，对应文件就是 dist/assets/readership.js。

如果你的网站每次构建都会清空 dist，应把脚本放入构建器会复制的静态资源目录。HTML 修改也要写在模板或源文件里，避免下次构建丢失。拿不准时，把“发布目录、文章模板、静态资源目录分别在哪里”作为一个单独问题先确认。

在文章列表的每张卡片中，文章标题和摘要后加一行：

<span class="readership-count"
      data-read-path="/articles/hello/">阅读 —</span>

不同卡片替换成各自的文章路径。在文章正文页的标题下方，也放同样的标签。

接着，只在正文页面的 <head> 中加上当前文章路径标记：

<meta name="readership-path" content="/articles/hello/">

这个标记告诉脚本“当前正在读哪篇”。列表页只展示数字，不加这条 meta，避免浏览列表时给每篇文章都加一次。

最后，在所有需要展示阅读量的页面、</body> 前面加入：

<script src="/assets/readership.js" defer></script>

把下面样式加到自己的 CSS 文件。text-align:right 让数字靠右显示：

.readership-count {
  display: block;
  margin-top: 14px;
  text-align: right;
  font-size: 13px;
  color: #637777;
  font-variant-numeric: tabular-nums;
}

本站现有脚本会自动识别自己的文章卡片。这里提供的入门版采用显式标签，省去了猜测你网站的卡片类名这一步。数字的显示与计数定义相同。

第 11 步：重新发布完整网站

先运行你网站原有的构建和检查，确认阅读量标签和脚本进入最终发布目录。然后按原来的方式发布完整网站：

• 使用 Git 自动构建的项目：提交源模板与资源修改，走原来的发布流程。
• 使用直接上传的 Pages 项目：进入原 Pages 项目，Create deployment → Production，上传完整发布目录或对应 ZIP。

ZIP 的根目录应该能直接看到 index.html。不要把运营记录、配置凭据和待审文章打进去，也不要只上传 readership.js 来替换整个网站。上传方式见 Pages Direct Upload 文档。

图 9：本站发布记录。上传文件成功之后，还要看到 Deployment complete；随后查询正式域名接口，而不只看预览域名。

第 12 步：用一次真实浏览完成验收

1. 打开正式文章列表，找到刚接入的文章，记下显示的数字。
2. 点进文章，等标题附近显示出阅读量。
3. 回到列表并刷新，查看该文章是否出现更新后的数字。
4. 在同一标签页内立即再次打开文章。按这套口径，30 分钟内重复访问应保持同一个累计值；其他读者同时访问时仍可能增加。
5. 最后用手机检查数字位置、字号和页面是否正常阅读。

新装时显示 0 很正常。显示 — 表示还没有取得数字，要检查接口和资源加载；不要在请求失败时强行显示一个 0。

本站这次保留了页面 HTML、脚本和接口核验记录：正式页面已经加载新版脚本，示例文章计数从 0 变为 1。10 月 13 日再次查看 Daily You 文章，页面显示“阅读 11”。这个数按上文的访问规则累计，也可能包含站长检查页面时的访问。接入自己的模板后，仍要按上面的桌面和手机步骤检查位置与样式。

五、遇到问题，从哪里查？

我这次就遇到了重复部署时报网络错误。前一次已经出现成功输出，后一次失败并不能直接说明线上网站坏了；应该打开正式地址检查当前状态，再决定是否重试。

六、以后每发一篇文章，顺手做这几件事

文章上线时，把路径加进 pages.json 并重新部署 Worker；更新列表和正文的路径标记；再发布网站，检查对应数字。若使用生成器，可以让程序从已公开的文章清单统一生成这些配置，避免维护两份名单。

同时，在隐私说明中交代：计数从何时开始、如何去重、保存什么、保留多久。本文方案保存文章路径、事件类型、随机请求标记和时间；去重明细保留七天，累计数字持续保留。计数数据库不存 IP，IP 用于边缘限流。Cloudflare 自身的平台日志另按你的账号设置管理。浏览器关闭会话存储时跳过写入。

这套示例适合小型个人网站，提供基础去重与限流。流量变大或出现刷量时，需要再检查数据库和 Worker 的用量、读取缓存与防滥用策略；使用前查看 D1 配额与 Workers 配额，不要把免费额度理解成无限使用。

每周复盘一次即可：哪篇文章被打开了，哪些搜索词带来了点击，哪次外部分享带来了访问，读者问了什么。累计阅读量能帮我看见文章的变化；是否值得继续写，还要结合真实反馈一起判断。

操作记录：2026 年 10 月 12 日；文档核对：2026 年 10 月 13 日。本文截图来自本站实际操作，截图中的域名用于说明；照做时填写你自己的域名、数据库和项目名。