一个站做了五六年，最怕的不是没流量，而是某天发现一条撑了半年的纯流量链接突然被人投诉侵权。投诉方给的证据里往往有一张截图：网址、标题和你站上完全一致，可内容你从来没写过。那多半是有人把你的文章原样抄过去，而且抄得比你还早被搜索引擎看到。

保护自己的手段说起来很多：版权声明、禁止右键、防盗链图片、DMCA 投诉、法律函。但真正便宜且长期有效的只有一条：让搜索引擎天然认得出「谁是最先发的那一份」。这道技术手段就是 canonical 标签加一套可验证的原创时间证据。本文只讲怎么把这两件事做对，包括几种看起来做了但其实错位的写法。

一、抄袭的第一现场通常不是你的站

内容被搬运后的常见路径是这样：你的文章上线，因为站点权重不高，抓取和收录都慢；搬运方把文章改写几个词、换个标题，发在一个权重更高的公众号聚合页或采集站上，两天就被收录了。等你的页面被收录时，搜索结果的「首发」判断已经偏向对方，你的页面反而被当成转载。

这说明两件事。第一，靠发出来之后的收录速度赢不了，必须在上线的那一刻就把「这是我的」这件事写进页面的结构化信息里。第二，判断原始版本靠的是时间信号和链接声明，而不是投诉通道，后者只能在已经发生问题后去补救，成本高得多、成功率也不稳定。

二、canonical 的三种写法，只有一种是对的

canonical 的作用是告诉搜索引擎「这个内容真正的地址是这一个」。它有严格的方向性：页面 A 声明归属页面 B，意思是 A 是 B 的副本。方向写反了，等于自己主动把原创页面标成了转载页。

# 正确：文章页声明自己就是原始版本，绝对地址
<link rel="canonical" href="https://www.example.com/1234.html">

# 正确：分页列表的后续页归属第一页（这是列表页的规则）
<link rel="canonical" href="https://www.example.com/tag/linux/">

# 正确：带 ?utm_source=xxx 的推广链接归属干净地址
<link rel="canonical" href="https://www.example.com/1234.html">

三种错误写法值得单独记住。第一，用相对路径 href="/1234.html"。理论上允许，但 CDN、镜像站、移动版子域这些场景下相对路径会被解析成各自的域名，等于给每个镜像都声明了一份原创，反而稀释了主站。第二，canonical 指向一个 301 跳转的地址。搜索引擎不会跟着跳转继续解析。第三，全站所有页面的 canonical 都写成首页地址，这种「复制模板忘了替换变量」的事故在主题切换之后特别常见，后果是整站的收录都归到首页。

检查方法很简单：随便抽十篇文章，把页面上 canonical 的地址抓出来，和地址栏逐个比对。不一致的一定要查，一致的比例低于九成说明主题模板有问题。

# 批量抽 20 个页面，打印 canonical 和地址栏
for cid in $(seq 1234 1253); do
  url="https://www.example.com/$cid.html"
  can=$(curl -s "$url" | grep -oE 'rel="canonical" href="[^"]+"' | head -1)
  echo "$cid  $can"
done

三、比 canonical 更原始的信号：时间

搜索引擎判断首发靠的主要是三个时间：抓取时间、页面里的发布时间、以及外部链接出现的顺序。前两个你能控制，第三个只能靠先发。所以页面里的时间必须真实、明确、机器可读，并且在被搬运之后不会跟着变。

<meta property="article:published_time" content="2026-11-03T08:15:00+08:00">
<meta property="article:modified_time" content="2026-11-06T21:40:00+08:00">
<time datetime="2026-11-03T08:15:00+08:00">2026-11-03</time>

三个常见错误。第一，发布时间和修改时间用了同一个字段，每次小改一个错字都把 published_time 更新成今天，读者和搜索引擎都会认为这是一篇新文章，首发证据直接作废。修改时间应该只在内容实质变更时更新，改错别字应该改 modified_time 而不是 published_time。

第二，时区没写。只写 2026-11-03T08:15:00 不带 +08:00，机器会按 UTC 理解，于是你上午八点发的文章在机器眼里是下午四点，跨天的情况下会整整差一天。这一天的差距在首发判断里可能就是致命的。

第三，时间是脚本生成时现算的。某些主题在渲染页面时才生成时间，导致每次抓取读到的「发布时间」都是抓取当天。这类问题的表现是站内所有文章的发布时间都挤在同一天，从搜索引擎的角度看就是一堆同时诞生的页面，没有先后，也就没有原创优先级。

正确的做法是把发布时间固化在数据库里，页面渲染时原样输出，不做任何换算。爬虫抓一百次看到的是同一个时间，这才是可信的信号。

四、Sitemap 里的 lastmod 是第二份时间证据

sitemap 的作用不只是告诉爬虫有哪些页面，里面的 lastmod 是搜索引擎判断「内容有没有更新」的主要依据。它有两个方向的错误。

写得太勤：每次构建都把所有页面的 lastmod 刷成当前时间。结果是搜索引擎每次都认为全站都更新了，跑过来的实际发现内容没变，之后就再也不信这个字段了。判断标准是 lastmod 应该等于这篇文章最后一次内容实质修改的时间，精确到天就够了。

写得太随意：所有页面都用站点构建日期，或者干脆省略。省略本身不算错，但等于放弃了一份免费的时间证据。对有几百篇文章的站，从数据库里按 modified 字段生成 sitemap 是几行 SQL 的事，成本极低。

<url>
  <loc>https://www.example.com/1234.html</loc>
  <lastmod>2026-11-03</lastmod>
</url>

还有个细节：lastmod 如果晚于今天的日期，整个 url 条目会被忽略。有些站按计划任务预先生成未来要发的文章并写进 sitemap，时间用了文章的发布时间（未来），这是最常见的「sitemap 里有但收录不了」的原因。

五、让抄袭者帮你反向证明

内容被搬走之后，如果对方是做正经站的，通常不会删掉你文章里的外链和图片。这给了你一个不太体面但很有效的手段：在每篇文章的正文里放一两个指向本站其他文章的内部链接，链接的锚文本带上你的品牌词或者站点的固定特征词。搬运方原样复制之后，那几条链接就成了指向你的反向链接，同时锚文本成了他页面里出现的你的品牌词。

更进一步的做法是在正文里嵌入一张带站点水印的示意图或一段引用块，引用块里写清楚「本文首发于某站某年某月」。搬运方如果只改了几个词，这段引用块往往会被原样留下，读者顺着找过来就是你的流量，同时这段文字本身也是很好的时间证据。

要注意的是，这两件事的目的不是「让对方下线」，而是让证据链在对方站上也成立。投诉的时候，你给出的不只是自己的页面，还有「对方页面上明确写着出处是本站」的截图，说服力完全不同。

六、上线之前该做的六项检查

把上面几节压缩成一份可以照着跑的清单，每项都有一句话的验证方法。

第一，每篇文章的 canonical 指向自己的绝对地址，抽取十篇比对。第二，canonical 的地址不能是 301 目标，用 curl -I 看返回码是不是 200。第三，published_time 和 modified_time 是两个独立字段，且都带时区。第四，站内所有文章的发布时间不应该是同一天，抽查三个月的文章看分布。第五，sitemap 的 lastmod 不晚于今天，也不应该每天都变。第六，页面右上角或文末有明确的发布时间文本，用户可见，而不只是藏在 meta 里。

第六项容易被认为多余，但它其实是给人工审核和投诉用的。搜索引擎看 meta，人看页面。一个连日期都不显示的页面，在投诉流程里很难证明自己是先发的。

七、真的发生了怎么办

如果已经被抄并且对方收录在前，处理顺序很重要：先在站内把上面六项补齐（很多站被抄的原因就是自己的时间信号是错的），再通过搜索引擎的侵权投诉通道提交，提交时引用三样东西：你的原始页面地址、对方页面地址、以及你自己的 published_time 与 sitemap 里的 lastmod。这三样构成一条内部一致的时间链，比「我发誓是我先写的」有效得多。

同时准备一份带站名水印的原始稿件截图或者编辑器里的修订记录。这类材料不是给搜索引擎看的，是给对方站点的运营者看的，很多人收到一封列清证据的邮件就会主动删除，比走投诉流程快得多。

最后一句：这类事做得最好的站，往往不是声明写得最狠的，而是技术细节最规范的。canonical 写对、时间写实、sitemap 写准，这三件事花不了一个小时，但它们决定了出事那天你手里有没有证据。