Your product's share links could be hurting your Google traffic

Index bloat is when Google indexes large numbers of low-value pages from your site, such as share links, previews or auto-generated pages, that you never meant people to find through Search. For B2B SaaS products with a Share or Publish button, Google now says those pages should stay out of its index by default.

Google made that explicit on 26 October 2026, when it updated its guide to preventing user-generated spam. Many product teams never made a decision about whether share pages belong in Google, so the default made it for them.

This guide from MADX Digital is for B2B SaaS founders and product or growth leads whose product creates public pages: shared reports, docs, boards, templates, AI chats, generated pages or prototypes. It covers what Google changed, how spam on share pages can become a problem for the whole site, how to check your own site in Search Console, and six questions to take to your developers.

What did Google change in October 2026?

On 26 October 2026 Google updated its guidance on preventing user-generated spam. Alongside its advice on comment forms and other user content, the guide now names hosting platforms and tools that let users publish "shared pages, generated content, or web apps", and says spammers may use them to create large numbers of pages that break Google's spam policies.

That describes a lot of SaaS: shared dashboards, published prototypes, shared AI chats and client boards. Each Share button can create a public URL on your domain, and unless someone chose otherwise, that URL can be crawled and indexed like any marketing page.

The new rule: only index content meant for Search

The new section of Google's guide to preventing user-generated spam is headed "Only index content meant for Search". It asks you to decide whether the pages users create are meant to be found through search engines, or opened only by people who have the link.

What Google now asks you to monitor

Google also added monitoring advice. It says to verify your site or subdomain in Search Console, so you receive email alerts if Google issues a manual action or finds a security issue, and to check the Page Indexing and Search performance reports "regularly for unexpected spikes in indexed pages, impressions, or queries that don't match your platform's purpose".

On the product side, it suggests tracking how many public pages are created and indexed, with alerts for spikes in newly published public pages or "a small number of users generating a large share of indexable URLs". That second signal fits B2B SaaS well: a spammer working from one free account would show up as one user publishing far more than anyone else.

How can spam on share pages become a site problem?

Google's new guide talks about indexing and spam, and it doesn't mention rankings. The wider risk comes from manual actions, which Google's help documentation says can apply to part of a site or all of it. The link between the two is our reading, and we set out the reasoning below so you can judge it.

Spammers look for open publishing tools

Any product that lets a stranger sign up and publish a public page on your domain is useful to a spammer. A free account can be used to publish pages of casino, pharmacy or link spam, on a domain that already has your brand's reputation behind it. Google's guide now names shared pages, generated content and web apps next to its advice on comment forms.

Google's manual action for this problem is described in plain words in its Manual Actions report help: "Google has detected spam on your pages submitted by site visitors."

A manual action can reach further than the bad pages

The same help page says the pages affected by a manual action can be "a subset of your site, or the entire site". That is general wording that applies to all manual actions. Google's new share-page guidance doesn't mention rankings or sitewide effects, and we're not claiming it does.

Our view is practical. If spam on share pages ever leads to a manual action, you don't get to choose how far it reaches. The safer default is to keep those pages out of the index before anyone abuses them, so there is nothing for spammers to gain.

Crawl time matters only on very large sites

You will also read that index bloat wastes crawl budget. Google's crawl budget guide does say that when many of the URLs it knows about are duplicates or unwanted, "this wastes a lot of Google crawling time on your site". But the guide is written for sites with 1 million+ unique pages that change weekly, or 10,000+ unique pages that change daily, and Google calls those numbers "a rough estimate" rather than exact thresholds.

If your marketing site has a few hundred or a few thousand pages, crawl budget is rarely the reason to act. A product domain with millions of public share URLs is different.

Where does user generated content SEO still make sense?

Some teams want user pages in Google on purpose: public template galleries, community showcases, integration directories. These can bring in signups, and Google's guide doesn't rule them out. It asks you to index content that is meant for Search.

Our verdict: index the gallery you curate, keep everything users create noindexed by default, and let users opt in to indexing only where you moderate what gets published. Google's guide supports a version of this for new accounts as well. It suggests you "consider adding the noindex robots meta tag on posts that come from new users" who have no reputation on your platform yet, and allow indexing once they have built one.

How do you tell if share pages are causing index bloat?

Two Search Console reports and one Google search will tell you whether share pages are in Google's index. It is a short job once you know the URL patterns your product uses for public pages, for example /share/, /s/, /p/, /view/ or a subdomain per user or workspace. Write those down first.

Check the Page Indexing report

In Search Console, open the Page Indexing report and look at indexed pages on your share paths. If share pages live on a different host from your marketing site (app.example.com, or one subdomain per customer), make sure that host is verified too. A Domain property in Search Console covers every subdomain, which makes this easier.

Check the Search performance report

Filter the Search performance report by page, using each share path. Look for queries that have nothing to do with your product: other languages you don't serve, brand names you have never heard of, gambling or pharmacy terms. That is the pattern Google tells platforms to watch for.

Share pages can also make Search Console data hard to read in a quieter way, by adding impressions and queries that have nothing to do with your marketing site.

Run a site: search

Google's manual actions help suggests searching your site with the site: operator in Google, adding commercial or adult keywords that are unrelated to your topic. For share pages, add the path as well, for example site:example.com/share/ casino.

The one row we would index is the curated gallery, because public templates can bring in signups. Keep it to pages you would be happy to see ranked: reviewed, moderated and with a clear owner on your team.

What should you ask your developers?

Six questions cover it. Most of the answers are product settings rather than SEO projects.

1. Do share pages send noindex by default? Either a robots meta tag in the page or an X-Robots-Tag: noindex HTTP header. PDF exports and other files need the header, because Google's noindex documentation says it "can be used for non-HTML resources, such as PDFs, video files, and image files".
2. Can Google still crawl share paths? Google's guide allows noindex or a robots.txt block, but the two don't mix. The noindex documentation says the page "must not be blocked by a robots.txt file", otherwise the crawler never sees the rule and the page can still appear in results if other pages link to it. That is why we prefer noindex. Keep share URLs out of your XML sitemap as well.
3. Do links inside user content carry rel="ugc" or rel="nofollow"? Google suggests adding "a nofollow or ugc rel attribute to all links in untrusted content", which removes much of a spammer's reason to publish. Our glossary explains rel="ugc".
4. Do new accounts start noindexed? Hold back indexing for new accounts until they have a reputation on your platform, and only for page types you have chosen to index.
5. Is every host that serves share pages verified in Search Console, with alerts? Verification gives you Google's manual action and security emails. Add your own alert for spikes in newly published public pages per day.
6. What happens to pages that are already indexed? Add noindex and keep the pages crawlable so Google can see it. Google says it can take months to revisit a page, and you can request a recrawl with the URL Inspection tool. The Removals tool only blocks a URL temporarily (Google says a successful request "lasts only about six months"), so use it as a stopgap for the worst pages while noindex does the lasting work.

If you are also deciding which AI bots may read your site, that is a robots.txt question for your marketing pages rather than your share pages. Our guide to AI crawlers covers it.

What to do this week

Treat share-page indexing as a product setting with an owner. Pick the default (noindex), decide which curated pages are exceptions, check Search Console for what is already indexed, and set an alert so a spike reaches someone on your team before it becomes a problem in Google.

If share pages are only one of several technical questions on your list, our SaaS technical SEO guide and our walkthrough of how to run an SEO audit for SaaS cover the rest. To hand them over instead, see our technical SEO service for SaaS companies. If you'd like us to look at how your site shows up in Google and in AI answers, request your free AI Search audit.

Frequently Asked Questions

What is index bloat?

Index bloat is when Google indexes many more of your URLs than you meant to publish for Search, such as share links, previews, filtered views or auto-generated pages. It is a symptom rather than a penalty. It makes Search Console data harder to read, and on very large sites it takes up crawling time. Share pages from SaaS products are one possible source.

Should SaaS share links be noindexed?

Yes, by default. Google's updated guide says pages created for direct sharing, collaboration or utility rather than search discovery should carry noindex or be blocked from crawling by default. We recommend noindex, and indexing only curated, moderated pages such as a public template gallery.

Is noindex or robots.txt better for share pages?

We recommend noindex. Google's guide allows either, but Google's noindex documentation says a page must not be blocked by robots.txt for noindex to work. A page blocked in robots.txt can still appear in results if other pages link to it, because Google never crawls it to see the rule.

Can user-generated pages get my whole site penalised?

Possibly, through a manual action. Google's Manual Actions help says an action can affect a subset of a site or the entire site, and it has a specific action for spam submitted by site visitors. Google's new share-page guidance does not mention rankings, so the safest course is to keep share pages out of the index by default.

How do I find shared pages Google has indexed?

List your share URL patterns, then check the Page Indexing report and filter the Search performance report by those paths in Search Console. Look for queries that don't match your product. A site: search on the share path with spam keywords, such as site:example.com/share/ casino, is a quick extra check.