Google's New UGC Spam Guidance (2026.10 update): Which Share Pages Should Be Indexed

The rule Google just wrote down

On October 26, 2026, Google added a two-paragraph section to its guide on preventing user-generated spam. It is the shortest part of the page and probably the one that will change the most product roadmaps, because it asks a question most teams have never put on a slide: should this URL be in Google's index at all?

The section is titled "Only index content meant for Search." Here it is in full:

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. 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's own changelog for the same day is more direct about the intent: the guide was updated with "guidance on blocking indexing of link-shared content and monitoring abuse in Search Console," so platforms can "keep user-created pages that aren't meant for Search out of the index and detect spam earlier."

That is it. No new manual action, no ranking system announcement, no penalty list. A default was recommended, and defaults are where most indexing accidents come from.

Who this is for. Teams that ship any URL a user can generate: share links, saved chats, public dashboards, template previews, app builds, generated reports, forum threads, profile pages, review pages, listing pages.

What you will finish with. A route-level verdict for every generated URL type, the control that actually removes it from the index, and a monitoring rule that catches the abuse pattern Google described.

Time. 45 to 90 minutes for a first pass on one product. A day if you have several URL generators and no route inventory.

Done looks like this. Every generated route is marked index, noindex, or private. The noindex routes return the directive server-side, not after JavaScript runs. Search Console shows those URLs as excluded by noindex, not as "Indexed, though blocked by robots.txt."

What changed, and what only looks new

Four edits matter. The rest of the page is unchanged, including advice from December 2025 that still applies.

What did not change: noindex on posts from new users until they earn reputation, and nofollow or ugc on links inside untrusted content. If you already do both, you are ahead of this update.

Worth saying plainly, because the reaction on X ran ahead of the document: this is guidance to platforms about their own URL supply. It does not create a new violation for a normal marketing site, and it does not change how any page ranks. It changes what should exist in the index.

One more piece of context explains the timing. At the end of July 2026, Claude share links and artifact pages turned up in Google's index, and reporting at the time described exposed medical records, API keys, and other private material before Anthropic closed the gap within days. The same coverage pointed at public app URLs on builders such as Replit and Lovable. Google rarely writes a new section for a hypothetical. This one had already shipped.

The question that decides every generated URL

Google's test is stated in one sentence, and you can apply it without guessing at intent: is this content meant to be found through search engines, or only accessed by someone holding the link?

In practice, four signals answer it. Score the route, not the individual page.

Three of four pointing at noindex is a clear call. Mixed results usually mean the route needs to be split: a public gallery that is indexable plus the individual outputs, which are not. That split is the single most common correct answer, and it is also the one most teams skip because it requires two templates instead of one flag.

A useful refusal test: if a stranger saw this URL in a search result with no context, would the title and snippet make sense to them? "Chat with Sam, Oct 24" fails. "Invoice template for freelance designers" passes. The failure is not about quality. It is about whether the page was built to be found or built to be sent.

Pick a control that actually removes the URL

This is where the new guidance can be followed literally and still fail. Google offers two options in the same sentence, and they are not equivalent.

Robots.txt controls crawling. It does not remove a URL from the index, and Google says so in the robots.txt introduction: a page disallowed there "can still be indexed if linked to from other sites," in which case the URL, and possibly anchor text pointing to it, can appear in results without a description.

Noindex controls indexing, but only if Google can fetch the page and read the directive. Google's noindex documentation is explicit: for the rule to work, the page must not be blocked by robots.txt, because otherwise "the crawler will never see the noindex rule."

Put those two facts together and the ordering matters:

One shortcut to avoid: X-Robots-Tag: none is not a neutral value. Google treats it as noindex plus nofollow. It is occasionally what you want, but teams copy it from a proxy config without knowing that.

Second shortcut to avoid: canonical tags. A canonical is a hint. If the page should not be in the index, say noindex.

Step 1: Inventory the routes that mint URLs

You cannot classify what you have not listed, and most teams underestimate their count because they think in features rather than route patterns.

Open the router, or the URL map, and list every dynamic segment. Typical offenders look like this:

• /s/:id, /share/:id, /p/:token
• /chat/:id, /conversation/:id, /thread/:id
• /u/:handle, /profile/:handle
• /app/:id, /build/:id, /project/:id
• /r/:slug, /preview/:token, /report/:id

Then confirm against what Google already knows, because your code and the index will disagree.

From the sitemap. Pull it and count what is in it:

curl -s https://example.com/sitemap.xml | grep -c "<loc>"
curl -s https://example.com/sitemap.xml | grep -oE "https://[^<]+" | sed -E 's#https://[^/]+##' | cut -d/ -f2 | sort | uniq -c | sort -rn

The second command gives you a rough path-prefix histogram. If a generated route appears in your sitemap, that is a bug in itself: a sitemap is a list of pages you are asking Google to index.

From Search Console. Open the Page Indexing report, filter by URL prefix for each candidate route, and note the counts. This is the only source that tells you what Google actually did with those URLs.

From server logs. Group Googlebot requests by prefix:

grep -i "Googlebot" access.log | awk '{print $7}' | cut -d/ -f2 | sort | uniq -c | sort -rn | head -20

Expected output: a list of route patterns with a URL count next to each, from at least two sources.

Quality check: every route that can return a 200 for a non-staff visitor should be on the list. If the sitemap count and the Search Console count differ by more than a few percent on the same prefix, find out why before you change anything.

If you find nothing: you probably have a client-side router. Search the frontend for route definitions rather than the backend, and check the network tab on a real share link.

Step 2: Classify each route in a table, not in a meeting

Write the verdict down where it can be reviewed. One row per route pattern is enough.

The table only works if three things are true.

Name one owner per row. Ambiguous ownership is why generated routes stay indexable for years.

Write the control next to the verdict, not later. "Noindex" is not a decision until someone knows whether that means a header, a template change, or a CDN rule.

Record the exception. If a route is noindex but a small subset should be public, write the subset condition down now. Retrofitting a carve-out six months later is how a noindex rule gets quietly removed entirely.

Step 3: Ship the control at the template level

Page-by-page fixes do not survive the next deploy. Apply the control where the route is rendered.

For HTML pages, put the tag in the server-rendered head. In a Next.js App Router page this is metadata; in Astro it is the layout's head; in Rails or Django it is the layout template. The exact syntax matters less than the location: it has to be in the HTML Google receives, not added by a client-side effect.

<meta name="robots" content="noindex">

For anything that is not HTML, a meta tag does not exist, so use the header:

X-Robots-Tag: noindex

That covers PDF exports, JSON responses, generated images, and CSV downloads. If those files are served from a CDN, set the header at the edge so new routes inherit it.

For a whole route family, a middleware rule is usually cleaner than touching every template:

// Express example: noindex every generated share URL
app.use(['/s', '/share', '/report'], (req, res, next) => {
  res.set('X-Robots-Tag', 'noindex');
  next();
});

Expected output: a deploy where every route marked noindex returns the directive on the first byte, for anonymous requests.

Quality check: curl -sI the live URL. You should see x-robots-tag: noindex in the response headers, and curl -s should show the meta tag in the source, before any script runs.

Recovery path: if the tag only appears after JavaScript executes, move it into the server render. If your framework cannot render head tags per route, use the header instead. Do not ship a JS-injected noindex and assume it works; Google describes the behavior for rendered noindex as not well defined.

Two more things belong in the same pull request. Remove noindex routes from the sitemap, since submitting a URL you do not want indexed is a contradiction Google resolves in its own favor. And add an expiry rule: when a share link dies, return 410 rather than leaving a 200 page with an empty state.

Step 4: Verify Googlebot can see the directive

Everything above is unverified until you check it the way Google will.

Check the response headers first:

curl -sI https://example.com/s/abc123 | grep -i x-robots-tag

Then check the initial HTML, before any script has a chance to run:

curl -s https://example.com/s/abc123 | grep -i 'name="robots"'

Finally, confirm robots.txt does not block the path. If it does, Google never fetches the page and never reads the directive:

curl -s https://example.com/robots.txt

Search Console is the final check. Request the URL in URL Inspection and read the verdict.

The correct result is "Page is not indexed: Excluded by 'noindex' tag." The result that means you have the trap is "Indexed, though blocked by robots.txt" — Google has the URL, cannot read the directive, and may keep serving it. If you see that, remove the robots.txt rule and let the noindex do the work.

You can also fetch the page as Googlebot sees it with a crawler simulator, which is faster than waiting for a recrawl when you are checking twenty routes: Googlebot Spider Simulator.

Expected output: every noindex route shows the excluded-by-noindex state within a few days of the next crawl. Routes created after the change should never appear in the index at all.

Recovery path: if a URL stays indexed after two weeks, check whether Google can fetch it at all, whether the page returns 200 for Googlebot, and whether a canonical or hreflang tag is pointing search engines elsewhere. Use the Removals tool only for a temporary block while you fix the cause; it is not a substitute for the directive.

When the share page is the growth channel

Some generated pages should be indexed, and blanket noindex would be a self-inflicted wound. These are the ones worth protecting:

If you are in one of these categories, Google's older advice still applies and is the better lever: noindex content from users without reputation, then lift it once the account has history. That gives you spam resistance without giving up the acquisition loop, and it is the pattern the guide recommended before this update.

The test for all three is the same. If the page earns impressions in Search performance for queries a stranger would type, it belongs in the index. If it earns impressions for its own URL string and nothing else, it does not.

There is a second-order effect worth naming. Public share URLs have been a cheap link surface for years: create a page on a platform with a strong domain, point a link at your own site, repeat across twenty properties. Patrick Stox put the count at 20-plus links from different platforms in the same thread. If platforms follow the guidance, that surface narrows. If they don't, Google now has a document to cite the next time it decides those pages are spam.

Step 5: Instrument the pattern Google described

The monitoring section is the part of the update most teams will skip, and it is the part that catches a real incident before it becomes a manual action.

Four checks, each with a place to look.

Search Console ownership. Verify the site or subdomain so manual action and security alerts arrive by email. If you run a platform with per-tenant subdomains, verify the parent and at least a sample of child properties; an alert that lands nowhere is not monitoring.

Page Indexing trend. Baseline the count of indexed URLs per generated route today, then watch for step changes rather than noise. A doubling of indexed URLs in a week on a route that should be static is the signal.

Search performance anomalies. Filter for queries unrelated to your product. Spam pages attract spam queries long before anyone files a complaint.

Creation-to-index ratio. This is the metric Google names, and the one almost nobody tracks: how many indexable URLs a single account can produce per day, and what share of new indexable URLs comes from the top 1% of accounts. A starting alert of 3x the trailing seven-day median for a single account is arbitrary but workable; tune it against your own traffic.

The same ratio works as a product guardrail. If a feature lets one user generate a thousand indexable URLs a day, it is an index-bloat feature whether or not anyone abuses it yet.

What the update is really saying

Strip the wording and Google is making an argument about supply.

For twenty years, spam policy described pages: thin, scraped, cloaked, stuffed. Those categories assume a human or a script decides to produce a page and Google decides whether it deserves to rank. Generated outputs break that model. One product decision can create a million URLs, all technically unique, all technically 200, most of them worthless to anyone who did not create them. Google cannot evaluate them one by one, and it has stopped pretending it can.

The reaction settled into two camps. The first read it as a warning shot: Marie Haynes asked whether new manual actions follow for AI tools and app builders, and Lily Ray treated the section as a signal about what Google is already fighting at scale, naming Claude artifacts, ChatGPT share pages, and social posts. The second camp shrugged. Most careful teams have noindexed user-generated reports for years, several replies argued, and Google's own generated pages are the bigger problem. Both readings can be true. What makes the guidance matter is not that the advice is new, but that it is now written somewhere enforcement can point at.

So the guidance moves the decision upstream. Platforms are now expected to decide, at the template level, whether a class of URLs belongs in the index. That is a governance question, not an SEO question, and it is why the advice sits in the spam guide rather than in the indexing documentation.

For AI search, the same logic applies in both directions. Google's AI features draw on the Google index, so a noindex directive removes a page from that pool as well as from blue links. If a generated page was earning citations in AI Overviews, expect those to stop. That is usually correct for a share link and usually wrong for a template page. Other AI crawlers follow their own rules, so decide separately which of them you want to be able to fetch those pages.

The practical takeaway is a sentence you can put in a design review: every URL a user can create is either a product surface or an index liability, and the template decides which.

FAQ

Does this apply to a normal marketing site?

Not unless your site mints URLs from user input. A marketing site publishes a set of pages that a person decided should exist, which is the opposite of the problem the guide describes. The scope line names hosting platforms and tools that let users publish shared pages, generated content, or web apps. If you run comments, a forum, or member profiles, the older advice applies: nofollow or ugc on links from untrusted accounts, and noindex for new users until they build reputation.

Should I use robots.txt or a noindex tag?

Noindex, and only one of the two on any given route. Google's sentence lists both options, but they do different jobs. A robots.txt Disallow stops the crawl, and a URL that is blocked but linked from elsewhere can stay in results with no snippet. Noindex works only when Google can fetch the page and read it. In practice that means a meta tag or a response header, and never a robots.txt rule on the same path.

Will noindexing share pages cost me traffic?

Check the route before you decide, not after. If a page earns impressions only for its own URL string, it is delivering no organic traffic and removing it costs nothing. The pattern that does lose traffic is taking down a public gallery along with the outputs inside it. Keep the gallery indexable, noindex what sits behind it, and watch Search performance for the gallery queries before and after.

Do AI search engines respect noindex?

Google's AI features do, because AI Overviews and AI Mode draw from the same index, so the directive removes a page from both blue links and AI answers. Other AI crawlers are a separate decision. Vendor behavior differs and changes without a changelog, so read each crawler's own documentation and fetch the page with that crawler's user agent instead of assuming one directive covers all of them.

Author: Grace Miller, AI Search Risk Analyst Tracking 200+ Policy Shifts at Auspia. Grace writes about platform rules, content risk, and policy-aware optimization.