RSS and Autoblog Theft

What RSS and autoblog theft is

An automated pipeline subscribes to your site's RSS or Atom feed, polls it continuously, and republishes each new post on a domain somebody else owns - often within minutes of publication. RSS and Atom are the two standard machine-readable formats a publishing platform emits so that software can be told what you have just published; almost every content management system produces one by default, and by default it carries the entire body of each post rather than a summary. That default is what makes the copy costless to make.

The practitioner name for the receiving site is an autoblog. The older term is splog, short for spam blog, a word that came into use in August 2005. Mechanically this is content scraping, and it shares the mechanism that decides the outcome: canonical selection, where Google groups near-identical pages into a cluster and shows one of them. But two properties make it worth a page of its own.

• It is a subscription, not a raid. A scraper crawls you once and holds a copy that immediately begins to go stale. An autoblog holds a standing subscription to everything you will ever publish, including your corrections. There is no single event to respond to and no end date.
• It is fast. A crawler has to find your new page. A feed reader is told about it, by you, the moment it goes live.

Latency is the whole argument

Every other copying attack starts at a disadvantage, because the copy is made after the original has been published, indexed and linked. Feed republishing is the one variant that closes that gap, and in some cases reverses it. A cron job polling your feed every five minutes has your post on another domain within five minutes. Whether Googlebot reaches your version in that window depends entirely on how often it visits you, and for a small or new blog the honest answer is often "tomorrow."

This is the condition under which a copy can plausibly be indexed before the original exists in Google's index at all - and it is the only route to that outcome that I find credible. It is worth being precise about what it does and does not establish. It establishes that Google can encounter the copy first. It does not establish that encountering the copy first decides which URL heads the cluster, because Google has never said that first-crawl order is a canonicalization signal, and it is not among the signals Google publishes. "First indexed wins" is a near-universal practitioner belief with nothing published behind it. Treat the speed gap as a risk worth closing, not as a mechanism you can point to.

Does it actually work?

Situationally, and less often than the industry's tone suggests.

Google's policies name this behavior twice, and both times they name the autoblog. The spam policies, last updated 28 August 2026, list reproducing content feeds from other sites without providing some unique benefit to the user under Scraping, and scraping feeds to generate many pages where little value is provided to users under Scaled content abuse, which Google defines as generating many pages primarily to manipulate rankings rather than to help users (Google's spam policies). Both are written as descriptions of the copier's conduct. Neither creates any exposure for the publisher whose feed was harvested, and Google's canonicalization documentation continues to say that duplication itself is not a spam-policy violation.

The economics collapsed around 2011. Auto-blogging was a mainstream black-hat business through roughly 2006 to 2011; the Panda update is when mass-produced, feed-fed blog networks stopped ranking well enough to pay for themselves. That removed most of the commercial motive. It did not remove the malicious one, and it has not stopped content mills consuming feeds as raw material for machine-rewritten pages.

On the record, John Mueller of Google was reported in May 2019 by Search Engine Journal as saying that other sites copying your content would not be something that negatively affects your website - a second-hand quotation from an office-hours session, but consistent with everything Google has published since.

And the case file is empty. I could not find a documented instance of an established site losing rankings to an autoblog: no disclosed experiment, no Google statement, no case study with a method attached. So the verdict is situational rather than documented. The theft is real, automated and instant; the injury is unproven except in the narrow circumstances below.

Those circumstances are: a new or low-authority blog with a slow crawl rate and a full-text feed; time-sensitive posts where the entire value is being first; and - this is the largest category by far - sites that never look, where the theft runs silently for years and the first symptom is a hosting bill or a licensing dispute.

The 2023 change that took away your fastest lever

One thing has moved against defenders, and it is specific and dated. In a Search Central blog post of June 2023 Google announced that it was deprecating the sitemaps ping endpoint, effective at the end of that year (Google Search Central, June 2023). That endpoint was the cheap, universal way to tell Google that something new existed the second it was published. It is gone.

Nothing replaced it for general web content. Google's Indexing API is not a substitute and does not pretend to be: its documentation limits it to pages carrying JobPosting markup or a BroadcastEvent embedded in a VideoObject. IndexNow, the push protocol that lets a site submit URLs the moment content is added, updated or deleted, does work - but its participating engines are Bing, Yandex, Naver, Seznam, Yep and Amazon, and Google is not among them (IndexNow FAQ). Implement it for the engines that accept it; understand that it does nothing for the one this page is about.

The practical consequence is that speed to index with Google is now earned through crawl cadence rather than requested through an endpoint. Since the attacker's side of the race did not slow down, the gap this attack depends on got marginally wider in 2023. It is a small effect and I would not oversell it, but it is the only change in this subject in a decade that moved in the attacker's favor.

Telling a feed pipeline from a crawler

This matters because the two have different defenses. A crawler is slowed by rate limits at the edge; a feed subscriber is slowed by changing what the feed gives away. Diagnose before you act.

• Feed access logs are the definitive evidence and they are specific to this attack. Pull the requests for /feed/, /rss, /atom.xml and their equivalents on your platform. The fingerprint is a single IP address or narrow range, hitting the feed at a fixed cron cadence - every five, ten or fifteen minutes, without variation - fetching only the feed and never an HTML page, image or stylesheet, usually with a generic HTTP library user-agent. Then compare the volume of feed requests against the number of humans who could plausibly be subscribed. A feed pulled thousands of times a day by a readership of forty is being harvested.
• Measure publish-to-copy latency. Publish a post, then search a distinctive sentence from it in quotation marks an hour later, and again the next day, excluding your own domain. Copies that appear within minutes are feed-driven. Copies that appear days later came from a crawler, and belong on the content scraping page instead.
• Plant a canary. Include, once, a unique nonsense string that exists nowhere else on the web, then search for that string later. It tells you unambiguously whether a copy exists and roughly when it was indexed. It is the cheapest evidence available anywhere in this subject and it costs you nothing.
• Check referral traffic and trackbacks. Many pipelines preserve the in-post links, because stripping them takes effort, so the autoblog shows up in your own analytics as a referrer, and on platforms that still process them, as pingback noise.

What it is mistaken for. Legitimate feed readers and aggregators poll on schedules too. So do uptime monitors, your own CDN's prefetching, and the newsletter automation somebody in marketing set up. Before you conclude sabotage, rule out a syndication license a colleague signed and forgot about - in my experience that accounts for a good share of "someone is stealing my posts" reports.

Closing the gap on your side

The defense that works on the mechanism, rather than on the symptom, is being crawled first. Nothing you do to the autoblog affects canonical selection; everything you do to your own indexing speed does.

1. Check whether you lost anything before you do anything. Inspect three recent posts in Search Console and read the Google-selected canonical. If it is your own URL and impressions are steady, the copy has cost you nothing in search, and steps four and five are optional. The page on plagiarism that outranks you covers that check and what its answers mean.
2. Give Googlebot fewer reasons to be late. An accurate XML sitemap with real lastmod values, a fast server response, and internal links to each new post from the pages Google already crawls most often - your home page, your category hubs, your most-linked posts. Crawl frequency responds to those over weeks, not hours, which is why this is work to do before you have a problem.
3. Adopt IndexNow for the engines that take it. It will not help with Google, but Bing and the other participants index faster when told, and your search visibility is not made of one engine.
4. Rate-limit abusive feed clients at the edge, on request rate and behavior rather than a blanket rule. A rule crude enough to catch a determined pipeline is usually crude enough to catch Googlebot, Bingbot or the reader applications your actual subscribers use, and that trade is always a loss.
5. Take down the copies that matter - the ones outranking you or monetizing your work - through the host, the registrar and Google's removal process, in that order. A dormant autoblog with no traffic is not worth the postage.

The full-text feed question, answered honestly

The standard advice is to switch the feed from full posts to summaries, so the copy arrives incomplete. It is worth considering, and it is a trade rather than a free win, which almost nobody says out loud.

What you gain: the pipeline republishes an excerpt instead of the article, which is less useful to the copier and less likely to cluster with your page. What you lose: the experience of every genuine subscriber, plus any legitimate integration that reads the feed - newsletter automation, podcast distribution, partner feeds, internal dashboards, and the aggregators that send you actual readers. Publishers routinely make this change in a panic and discover the breakage a month later.

And the evidence for the gain is weaker than the recommendation's popularity suggests: whether summary feeds measurably change ranking outcomes has never, as far as I can find, been tested publicly. It is a reasonable precaution for a new blog whose feed serves few real subscribers. It is a poor trade for an established publication whose feed is part of how it is read.

Why takedowns underperform here

Copyright removal works page by page. A standing subscription produces a new infringing page every time you publish. That asymmetry is the practical limit of the legal route against an autoblog, and it is why closing the feed side matters more than filing.

A notice to the host removes the content; a notice to Google removes the URL from search results and leaves the page on the web. Google publishes an average processing time of approximately six hours for web-form search removal requests, which is fast, but it is fast per URL against a pipeline that generates them indefinitely. Notices must be accurate, because a knowing material misrepresentation in one carries statutory liability for damages and fees under 17 U.S.C. §512(f), and because a rejected batch teaches you nothing.

Two routes work better against this specific target. The advertising network is usually the fastest remedy available: an autoblog exists to monetize, and removing the money is easier and more permanent than removing the pages. And a spam report to Google is unusually well founded here, because feed republishing at scale maps directly onto two named policy categories rather than requiring a judgment call. Google says only that it may use such reports to take manual action, so treat it as evidence-building rather than as a remedy - but the report you file about an autoblog is better grounded than most.

Common mistakes

• Killing the full-text feed in a panic and breaking the newsletter, the podcast feed and three partner integrations, to defeat a copy that was ranking for nothing.
• Blocking by user-agent or IP range too broadly and catching Googlebot, Bingbot or real readers. This causes a genuine ranking loss where the theft caused none - the most common way people turn a nuisance into an injury.
• Mass-disavowing autoblog domains. Disavow addresses links, not republished text, and Google already discounts this class of link without being asked.
• Filing a reconsideration request when Search Console shows no manual action. There is nothing to reconsider and you have spent a channel that matters.
• Filing notices one URL at a time against a pipeline, instead of going after the host or the advertising account.
• Assuming the autoblog caused the drop. Establish the date the traffic changed first. Autoblogs are found during investigations far more often than they are the reason for one.

Frequently asked questions