How to keep user-generated and shareable pages out of Google's index — and avoid a UGC-spam manual action (2026)
Keep user-generated and shareable pages out of Google's index after the 2026 UGC-spam update: decide what's meant for Search, noindex the rest, watch Console.
On October 26, 2026, Google updated its "prevent user-generated spam" guide and, for the first time, named the services it applies to: not just forums and comment sections, but any tool that lets users publish shared pages, generated content, or web apps. Its central new instruction, in a section titled "Only index content meant for Search," is to keep user-created pages that exist for sharing, collaboration, or utility out of the index by default. The warning underneath it is the part worth acting on — a platform can receive a manual action for the spam its users publish, so if you run any surface where people (or an AI) can spin up public pages, the hygiene is now your problem before it is Google's.
This is the defensive task: deciding what to exclude and excluding it correctly, so a flood of thin or auto-generated URLs never drags your whole property into a penalty. It is the mirror image of getting your good content found — for that side, see [how to get your user-generated content indexed by Google](/how-to/get-user-generated-content-indexed-by-google); for the trend-level read on why UGC spam and AI spam converged, the guide on [Google's crackdown on UGC SEO spam and AI-generated content](/guides/google-ugc-spam-ai-content-crackdown). The steps below run in order: triage your page types, see what is actually indexed, apply noindex the way that works, know when robots.txt is enough on its own, gate new accounts, and wire up the monitoring Google now says to run.
The steps
Decide, per page type, what is genuinely meant for Search. This single decision is the whole update. Go through every kind of page users can create on your surface — profiles, shared documents, one-off generated outputs, saved tool states, share links, exported artifacts — and ask whether a stranger searching Google should land on it, or whether it exists only for the person holding the link. Sort each type into "meant for Search" (substantive, discoverable) or "meant for sharing or utility" (the default-noindex pile). Do it by template, not page by page, because the generator keeps minting new URLs and you need a rule that applies to all of them.
See what Google has actually indexed, not what you assumed. Open the Page Indexing report in Search Console and export the indexed URLs. Compare that set against your "meant for Search" list from step one. The gap — indexed URLs that belong to your sharing or utility templates — is exactly what the update wants out of the index, and often it is far larger than operators expect because share pages get linked and crawled without anyone deciding they should rank. Anything on the sharing side that is already indexed is your remediation backlog.
Apply noindex the way that actually removes a page — a meta tag or HTTP header. For every page type you marked sharing or utility, add a robots meta tag — <meta name="robots" content="noindex"> — in the page's HTML head, or send an X-Robots-Tag: noindex HTTP header (use the header for non-HTML files like PDFs, or when you cannot edit the markup). Set it as the default in the template so every new page of that type is born noindexed, rather than retrofitting after a spike. A crawlable page carrying a noindex rule is the reliable way to keep a URL out of results.
Know when robots.txt is enough on its own, and when it isn't. Google's October 26 update lists two acceptable defaults for pages not meant for Search: a noindex rule (robots meta tag or X-Robots-Tag header) or blocking the page in robots.txt. They aren't interchangeable for every page, though. Google's own robots.txt documentation is explicit that the file "is not a mechanism for keeping a web page out of Google" — a URL blocked in robots.txt can still surface as a bare link with no description if something else links to it, and because a blocked page is never crawled, Googlebot also never gets the chance to read a noindex rule placed on it. For pages that will genuinely never be linked anywhere (one-off internal tokens, say), robots.txt is fine. For anything that could plausibly get linked — most shareable pages — use noindex on a page that stays crawlable, since that is the method that still removes a URL even after it has already been found.
Noindex posts from brand-new accounts until they build reputation. Google's "identify spammy accounts" advice targets the entry point for most UGC spam: fresh accounts with no track record. Add a noindex robots meta tag by default to posts from new users, and lift it once an account has demonstrated it is legitimate — earned engagement, cleared moderation, time on the platform. This keeps opportunistic spam out of the index without blocking your genuine members, because most comment spammers specifically want their content to show up in Search.
Verify your site — and each subdomain — in Search Console for manual-action alerts. A user-generated-spam manual action can be applied to a page, a section, or the whole property, and you will not see it coming unless Google can reach you. Verify ownership of your site, and verify any subdomain that hosts UGC separately, so you receive the email the moment Google issues a manual action or flags a security issue. This is the cheapest insurance there is: it is how you learn about a penalty while you can still fix it, rather than from a traffic chart a week later.
Set up spike monitoring on Page Indexing and Search performance. Google now tells platforms to watch for abuse signals directly. Check the Page Indexing and Search performance reports on a regular cadence for unexpected jumps in indexed pages, impressions, or queries that do not fit your platform's purpose — and specifically for the mass-generation fingerprint, where a handful of accounts produce a large share of your new indexable URLs. Track those numbers over time and alert on anomalies, so you catch a spam wave at dozens of pages instead of discovering it at tens of thousands.
Keep the pages that should rank crawlable and genuinely substantive. Do not over-correct. The update targets utility and sharing pages, not useful community content — a well-answered forum thread, a real review, a substantive profile still belongs in the index. Leave those crawlable and strong, and keep publishing first-hand content Google wants to surface. The target state is a lean, high-quality indexable footprint sitting alongside a large, properly noindexed sharing layer — not an empty index you pruned in a panic.
Common gotchas
Robots.txt is one of Google's own listed defaults for pages not meant for Search, but it has a real limit: a blocked page can still show up indexed as a bare URL if something links to it, and blocking crawl access also hides any noindex rule from Googlebot. Reach for noindex on a crawlable page whenever a page could ever get linked.
noindex only works on pages you control. You cannot de-index a third-party platform's URL — if user spam lives on a site you don't own, your only levers are reporting it or asking the owner to remove it.
A UGC-spam manual action can hit the whole property, not just the offending pages, which is exactly why proactive hygiene beats cleanup — a few thousand junk URLs from one abusive account can taint the site that hosts your real content.
The Search Console Removals tool is a temporary hide (about six months), not a permanent exclusion. Use it to buy time during an incident, but the durable fix is a noindex rule on the page.
Retrofitting noindex onto one batch while the generator keeps minting indexable pages is a losing race. Make noindex the template default so new pages are born excluded.
Don't confuse 'not meant for Search' with 'low quality.' A genuinely useful shared page can still be noindexed because nobody searches for it by query — the test is search intent, not merit.
Where Kompozy fits
Be honest about the boundary first, because it defines where [Kompozy](/) fits a task like this: Kompozy does not set your noindex tags, edit your X-Robots-Tag headers, or configure robots.txt — those are a developer-and-SEO job on infrastructure you control, and the steps above are the real work. What Kompozy changes is the pressure that creates the risk in the first place. The reason operators let thin, auto-generated pages pile into the index is usually a reach problem: they are chasing discovery with volume. Solve the reach problem a better way and the temptation to mass-publish indexable junk disappears.
That better way is to keep your indexable footprint deliberately lean and carry reach through the sharing layer Google is not trying to index at all. Kompozy is a full content generation and multi-platform publishing engine across [18 output formats](/glossary/output-buckets), and it is built to produce genuine variety from one idea — a [Clipped Short](/glossary/clipped-short), a brand-exact carousel, a [short avatar video](/glossary/persona-shorts), a quote graphic, a text post — not the same skeleton stamped across a hundred URLs that both the UGC-spam and scaled-content tests demote. So the handful of substantive pages you do keep indexable (your Blog Articles and Newsletters, published to a destination you own — GHL Blog, WordPress, a custom webhook, or Mailchimp for email) stay few and strong, while [Autopilot](/glossary/autopilot) fans the native social versions across the eight social platforms on a cadence. Noindexing a utility page costs you nothing when your discovery never depended on it.
Two defaults keep that lean footprint honest. A single [Persona Brief](/glossary/persona-brief) governs voice and banned words across every piece, so what you publish reads as one accountable identity rather than generic filler, and Autopilot schedules behind a per-post human review gate — the same verify-before-publish step the surrounding guidance now expects — so nothing thin ships to a page you want indexed. Creator ($49/mo for 2,500 credits) fits a solo operator keeping one clean blog plus a native social presence; Pro ($499/mo for 18,000 credits) suits a brand or platform running the full owned-plus-social cadence without padding the index; Enterprise is available through Contact Sales. Kompozy will not de-index a page for you — it removes the reason you would ever have published the page that needed de-indexing.
Frequently asked questions
Can Google penalize my site for spam that my users post?
Yes — Google's updated user-generated spam guidance warns that platforms and tools can receive a manual action for the spam their users publish, and it can apply to a page, a section, or the whole property. That is why the October 26, 2026 update tells operators to noindex sharing and utility pages by default and to monitor Search Console for spikes. Proactive indexing hygiene is how you avoid the penalty rather than clean up after it.
Should I use robots.txt or noindex to keep a shareable page out of Google?
Google's October 26, 2026 update lists both as acceptable defaults for pages not meant for Search, but they behave differently. Robots.txt only blocks crawling, and Google's own documentation says the file "is not a mechanism for keeping a web page out of Google" — a blocked URL can still appear indexed as a bare link if something else links to it, and blocking crawl access also stops Googlebot from ever reading a noindex tag on that page. noindex on a page that stays crawlable is the method that still removes a URL once it could be found, so use it for anything that might get linked; reserve robots.txt for pages you're confident will never be linked at all.
What counts as a page "not meant for Search"?
Pages built for direct sharing, collaboration, or utility rather than public discovery — shared documents, one-off generated outputs, saved tool states, share links, thin auto-created profiles. The test is intent: would someone find this by typing a query into Google, or does it only make sense when opened from a link? If it is the latter, Google's guidance says noindex it by default.
Will noindexing all those pages hurt my rankings?
No — it generally helps. Removing thin, utility, and sharing pages from the index concentrates crawl budget and quality signals on the pages that are supposed to rank, and it keeps a flood of junk URLs from dragging the whole property's perceived quality down. The pages you keep indexable — substantive, first-hand, discoverable content — are unaffected, which is the point of separating the two.