站长的日常，是"改完还得盯着生效"

上线一个新页面，最耗精力的往往不是写代码，而是确认它在各个环节都正确生效：搜索引擎有没有把带参数和不带参数的同一个页面当成两篇收录、社交平台分享出去会不会变成一张白板、换了域名的解析是不是所有人都能尽快访问到、发出去的邮件有没有被对方服务器判成垃圾。站内近期上线了五款面向站长的网络工具，正好覆盖这几层。这篇按"改完站之后要盯的事"把它们串一遍，需要深入网络排查的可以看《网络排查工具箱：从 ping 到 TLS 的 30 款浏览器工具》。

治重复收录：URL 规范化

改版、上活动、接广告投放之后，同一个内容常常有好几个地址：example.com/product?id=1、example.com/product/1、example.com/product/?utm_source=weibo。浏览器看着都正常，爬虫却当成三篇独立页面，权重被摊薄，收录还可能选错主版本。URL规范化工具 的做法是把任意 URL 拆成协议、主机、路径、查询参数逐段规整：把 scheme 和 host 统一小写、去掉默认端口、删掉 utm_* 这类跟踪参数、把参数按字母排序、折叠多余的斜杠和 ./、../ 片段，最后给出一枚规范链接（canonical URL）和对应的 <link rel="canonical"> 标签。

用法上有两条经验：一是先定死规则再批量跑。确定"最终对外只留不带参数的那一枚"，把整站 URL 丢进去生成 canonical，比逐页手动加标签省事；二是规范化和 301 要配套。canonical 只是告诉搜索引擎"以哪枚为准"，真正把旧地址的权重转移过去还得靠 301 重定向。规范链接在浏览器本地算出，整站的 URL 清单不用上传到任何第三方。

让解析尽快生效：DNS 缓存刷新

换了域名或者改了 A 记录，最尴尬的是"我这边好了，客户那边还打不开"。原因是 DNS 记录带着 TTL（生存时间），浏览器、操作系统、LocalDNS 层层都缓存着旧地址，TTL 没到期之前谁都可能还在访问老 IP。DNS缓存刷新 把各平台手动清缓存的命令整理成一键复制：Windows 的 ipconfig /flushdns、macOS 的 sudo dscacheutil -flushcache 加 sudo killall -HUP mDNSResponder、Linux 下 systemd-resolved 与 nscd 的对应命令，浏览器自己的缓存（Chrome 的 chrome://net-internals/#dns、Firefox 的 DNS 缓存开关）也一并给了入口。

一个实操顺序值得记：改记录前先把 TTL 调小（比如从 3600 降到 300），改完观察期过去再把 TTL 调回来；换完记录自己测试时，先刷系统缓存再刷浏览器缓存，顺序反了容易误判"还没生效"。

别让分享变成白板：Open Graph 验证器

文章写得好，分享到微信、微博、X 或 Slack 却只显示一个光秃秃的链接，损失的是点击率。症结通常在页面的 og: 元标签：og:title、og:description、og:image 缺一个，或者 og:image 的绝对 URL 写错、图片太大抓取超时。Open Graph验证器 解析目标页面的 og: 与 twitter: 标签，把字段逐条列出来，再按各平台的抓取规则模拟生成一张社交预览卡片，哪一字段缺失、图片尺寸不合规格、标题会不会被截断，一眼就能看到。

调预览时有两个高频坑：og:image 必须是绝对地址并带协议头，相对路径很多平台不认；图片最好走 https 且体积别太大，超时的图常被平台直接放弃抓取回退成无图。改一次验证一次，卡片稳定出图再上线。

域名归属与邮件送达：TXT 记录编辑器

TXT 记录是站长的"多重身份凭证"：验证站点所有权（Google Search Console、各类建站平台）、防钓鱼的 SPF、DKIM、DMARC 全靠它。TXT 也是最容易写错的记录——多一个空格、少一对引号、SPF 里 include: 的域名拼错、一条记录超过 255 字符没拆分，都会让验证失败或邮件被判垃圾。TXT记录编辑器 用填空的方式生成规范记录：选 SPF 就按 v=spf1 include:_spf.xxx.com -all 的结构引导你加服务器和机制，选 DKIM/DMARC 给对应模板，生成后顺带做一遍语法校验，把常见的空格、引号、all 机制缺失标出来。

新手建议先只做 SPF 并保持宽松（-softfail 或 ~all），确认业务邮件全部走已知发信服务后再收紧到 -all，DKIM 与 DMARC 再逐步补齐——一上来就 -all 又漏配某个发信方，很容易把自己的正常邮件挡在门外。

认设备、查故障：MAC 地址厂商查询

运维和客服常遇到"这台设备到底是什么牌子"的场景：网络里冒出一个陌生 MAC 不知接入的是谁、售后要判断设备年份和型号、排查是不是有隐私随机 MAC 在反复变化。MAC地址厂商查询 通过 MAC 前 3 个字节（OUI 前缀）反查注册厂商，支持批量粘贴一整个列表；对现代手机和电脑默认的随机化隐私 MAC，它会标出来——这类地址不属于任何已注册厂商段，别把它当成异常设备。配合站内已有的 WHOIS查询 看域名注册与到期、DNS查询 看 A/CNAME/MX/TXT 记录全貌、接口报错时对着 HTTP状态码速查表 判断是 404 路径错、403 权限拒还是 502 上游挂，站长的解析与收录这条链就基本齐了。

症状对照：该开哪一款

症状先开再看
同一页面被收录成多份URL规范化工具DNS查询（解析是否指对）
换域名后有人还打不开DNS缓存刷新DNS查询
分享出去没图没描述Open Graph验证器HTTP状态码速查表
邮件大量进垃圾箱TXT记录编辑器（SPF/DKIM）WHOIS查询
网络里冒陌生设备MAC地址厂商查询—

常见问题

这些工具会不会把我的域名、URL 清单传出去？

解析与生成类（URL 规范化、TXT 记录生成与校验、MAC 厂商查询、DNS 缓存命令展示）都在浏览器本地完成，不落服务器日志；真正需要联网抓取的只有 Open Graph 验证器，它访问的也是你主动要验证的公开页面，不碰后台和数据库。

canonical 和 301 到底先做哪个？

两者解决的不是同一个问题，建议一起上：301 负责把旧地址的流量与权重真正转移过去，canonical 负责在同一时刻仍有多枚可访问地址时告诉搜索引擎"以哪枚为准"。只加 canonical 不做 301，旧地址的权重还是散着的。

小结

改版和上线之后要盯的四件事，各有一款落点：重复收录交给 URL 规范化，解析生效交给 DNS 缓存刷新，社交预览交给 Open Graph 验证器，邮件送达与域名归属交给 TXT 记录编辑器，认设备用 MAC 厂商查询，配上 WHOIS、DNS 查询和 HTTP 状态码三件老伙计。这些解析与生成本地完成、不留痕迹，站长的配置数据继续留在自己机器上。