Google Tells Platforms: Noindex Share Pages Not Meant for Search

Google added a new "Only index content meant for Search" section to its spam guide on Oct. 26, telling websites to apply a noindex tag or block crawling via robots.txt by default on pages built for direct sharing, collaboration or utility.

The change targets platforms that let users generate shareable pages, and Google's changelog ties it directly to "blocking indexing of link-shared content."

What does the new section say?

The section follows the guide's advice on spotting spammy accounts and reads: "If your service lets users create shareable pages, generated outputs, or interactive tools, consider whether that content is meant to be found through search engines or only accessed directly by people with a link."

It continues: "When pages are created for direct sharing, collaboration, or utility rather than public search discovery, apply the noindex rule (using a robots meta tag or X-Robots-Tag HTTP response header) or block crawling in robots.txt by default."

Google also sharpened the guide's opening paragraph. It already warned that hosting platforms "may be similarly open to abuse." The updated sentence adds "tools that let users publish shared pages, generated content, or web apps," and now says spammers may create a large number of "pages or sites" — where it previously said only sites.

One piece of advice carries over unchanged from the version last updated Dec. 10, 2025: apply noindex to posts from new users until they build a reputation on the platform.

The takeaway: if your platform generates share URLs or app pages, Google now expects indexing controls by default, not after the fact.

Noindex or robots.txt — which one works?

The two methods are not interchangeable, and Google's own documentation explains why it matters.

• A page "that's disallowed in robots.txt can still be indexed if linked to from other sites," according to Google's robots.txt introduction. Google won't crawl it, but the URL and possibly anchor text can still appear in results, without a description.
• The noindex rule only works when robots.txt isn't blocking the page, because otherwise "the crawler will never see the noindex rule."
• Google's "Control what you share" page, updated Oct. 21, lists robots.txt as applicable to "images and video" and noindex as applicable to "all content types."

There's a real-world example of the tension. On July 27, Search Engine Journal's Matt Southern confirmed that Claude's share path was blocked by a "Disallow" directive in robots.txt. Those share pages also returned a "none" value for the X-Robots-Tag HTTP response header — which Google treats as equal to both noindex and nofollow, per its robots meta tag documentation. What Google saw when it first found those links remains undetermined.

In plain words: a robots.txt block stops crawling, but it doesn't guarantee the URL stays out of results — and it can block Google from ever reading your noindex rule.

What should platforms monitor now?

The Oct. 26 update adds concrete monitoring steps:

• Verify your website or subdomain in Search Console so you receive emails about manual actions or security issues.
• Check the Page Indexing report and Search performance report for "unexpected spikes" in indexed pages, impressions or queries that don't align with your platform's intent.
• Track creation and indexing at the platform level, with alerts for spikes in newly published public pages or "a small number of users generating a large share of indexable URLs."

Google's changelog says the update aims to help platforms "keep user-created pages that aren't meant for Search out of the index and detect spam earlier."

For share links, generated outputs and app pages, the practical check is simple: make sure any noindex rule can actually reach Googlebot. A robots.txt block on those pages means Google never reads it — and the Page Indexing report's "Indexed, though blocked by robots.txt" status is where those stray URLs will show up in Search Console.