Google now says share links should stay out of Search by default. Four questions for every page your product creates

What Google changed

On October 26, Google updated its Search Central page on preventing user-generated spam. The page used to be mostly about comment forms and forum profiles. It now speaks directly to products that create pages for their users: "Hosting platforms and tools that let users publish shared pages, generated content, or web apps may be similarly open to abuse."

There's a new section titled "Only index content meant for Search." It says that if your service lets people create shareable pages, generated outputs or interactive tools, you should think about whether those are meant to be found through search engines or only opened by people with the link. When they're made for direct sharing, collaboration or utility, Google says to apply noindex, through a robots meta tag or the X-Robots-Tag header, or to block crawling in robots.txt, by default.

The update also adds monitoring advice, which we'll come to. Google's stated reason, in its documentation log, is to help platforms keep pages that aren't meant for Search out of the index and catch spam earlier.

Who this is for

It's tempting to read this as advice for website builders and AI app platforms, and it is. But a lot of ordinary products create pages too:

A shared quote or proposal. A saved cart someone sends to a partner. A report or chart a user exports as a link. A booking confirmation page. A public profile. An AI tool's output that gets its own URL so people can share it. A preview link for a draft.

Each of those is a page with your domain on it. If it's crawlable and nobody decided otherwise, it can end up in Google. At best that's clutter in your search results. At worst it's somebody else's spam, or somebody's private details, sitting under your name. Every page your product creates is a page with your domain on it, whether or not you wrote a word of it.

The four questions

Run these for each type of page your product generates, not for each page. Most products have a handful, and the list is usually longer than the team expects once someone actually writes it out.

1. Would a stranger searching for something be glad to land here? A public recipe someone published on your platform, maybe. A shared cart, a draft preview or a one-off generated summary, almost never. If the answer is no, that page type should be noindex by default.

2. Do you know who made it? Pages from long-standing, verified accounts carry less risk than pages from an account created ten minutes ago. Google's existing advice on this page still applies: keep content from new users out of the index until they've built some reputation on your platform.

3. Could it contain something private? Quotes with prices, confirmations with addresses, reports with internal numbers. If a page could hold anything a user wouldn't post publicly, keeping it out of Search isn't just about spam. It's about not publishing your customers' information.

4. Would you notice if ten thousand appeared overnight? This is the abuse question. If someone scripted your share feature to mass-produce pages stuffed with links, how long before anyone on your team saw it? If the honest answer is "when our rankings dropped," you need the monitoring below.

What to do with the answers

Default to noindex for share-type pages. Send the X-Robots-Tag header from the server, or include a robots meta tag in the page. Setting it at the template or route level means nobody has to remember it for each new feature.

Know the difference between noindex and a robots.txt block. Google lists both. A robots.txt block stops Google from crawling the page, which also means it can't see a noindex tag on it, so a blocked URL can still show up in results if other sites link to it. For pages that must never appear, noindex on a crawlable page is the more reliable choice.

Make public an opt-in. If some pages should be findable, like a published portfolio, let the user choose to make them public, and only then remove noindex. Consider requiring an account with some history first.

Mark untrusted links. Links inside user-created pages should carry rel="ugc" or rel="nofollow," as Google's guidance already recommends.

Write it down. A short table: page type, indexable or not, and why. When the next feature ships a new kind of link, the table is the first place to check.

Watching for abuse

Google's new monitoring advice is specific, and most of it is cheap.

Verify your site, or the subdomain where user pages live, in Search Console, so you get the emails about manual actions and security issues. Check the Page Indexing and Search performance reports regularly for sudden jumps in indexed pages or impressions, or for queries that have nothing to do with what your product does.

Inside your own product, track how many public pages get created and indexed, and set alerts for spikes in new public pages, or for a small number of accounts creating a large share of them. That last signal catches most automated abuse early, before it shows up anywhere in Google.

When an alert fires, have a plan ready. Someone needs the access to switch a page type to noindex in minutes, suspend the accounts involved and remove the pages. Google's guidance also suggests making it easy to remove related spam once you find one example, for instance other accounts from the same IP address. Write those steps down now, while nothing is on fire, and make sure more than one person can carry them out.

It also helps to check the past, not just the future. Search Google for your share-link path with a site: query and see what's already indexed. Anything that shouldn't be there can get noindex now, and it will drop out as Google recrawls.

If your product creates pages for its users and you'd like help working out which should be public, or adding the controls and monitoring, our web applications team builds exactly that kind of plumbing. Talk to us.

Related work: Sutton Place.