Should Your SaaS Share Links Show Up in Google?

Should your share links show up in Google?

Usually not. If your product lets users create pages, outputs, or tools that are meant to be opened by whoever holds the link, Google now says plainly that you should decide whether that content belongs in search at all. For most B2B SaaS share links, the honest answer is no, and you should block indexing on purpose.

On October 26, 2026, Google updated its guide on preventing user-generated spam. The change log on Google Search Central says the update adds guidance on blocking indexing of link-shared content. It is a small documentation edit, but it lands on a problem I see in a lot of software products.

Most SaaS teams think about share links as a product feature. Very few think about them as pages that a search engine might find, crawl, and show to strangers. This update is a good prompt to check.

What exactly did Google change?

Google added a section to its user-generated spam guide about shareable pages. It says that if your service lets users create shareable pages, generated outputs, or interactive tools, you should consider whether that content is meant for search engines or only for people with a link. Then it tells you how to keep it out.

The guidance names two routes. For pages created for direct sharing, collaboration, or utility rather than public discovery, Google says to apply the noindex rule using a robots meta tag or an X-Robots-Tag HTTP response header, or to block crawling in robots.txt by default.

The same guide keeps its older advice too. It suggests adding a noindex robots meta tag to posts from new users and allowing indexing once a user has built some reputation. It also suggests a nofollow or ugc rel attribute on links inside untrusted content. None of this is new as a technique. What is new is that Google now calls out link-shared content by name.

Why does this matter for B2B SaaS products?

Because so many SaaS products now generate pages on behalf of users. Shared reports, public dashboards, AI generated summaries, proposal links, calculators, and embedded forms all live at real URLs. If those URLs are crawlable and get linked anywhere public, they can end up in search results under your domain, with content you did not write.

That creates three risks I care about. The first is spam. If anyone can create a public page on your domain, someone will eventually use it to host junk, and your domain carries the cost. The second is privacy. A customer who shares a report with a colleague does not expect it to be findable by a stranger. The third is dilution. Thousands of thin, user-made pages can crowd out the pages you actually want to rank.

AI generated outputs make this sharper. A product that turns a prompt into a shareable page can create a lot of URLs very quickly. Each one might be useful to the person who made it, and almost none of them are useful to a searcher. That is exactly the pattern this guidance is written for.

Is robots.txt enough to keep share links out of Google?

Not on its own. Google's own documentation says robots.txt is not a mechanism for keeping a web page out of Google. It controls crawling, not indexing. Google says it may still index a disallowed URL if that URL is linked from other places on the web.

This is the part I think teams will misread. The new guidance lists robots.txt as one option, and it is a reasonable default for keeping crawlers away from a whole folder of share links. But if one of those links gets posted on a forum or in a public doc, the URL can still appear in results.

If you need a share link to stay out of search results with more certainty, use noindex, or put the content behind a login. Google's docs say both of those keep a page out of Google. Pick robots.txt when your main goal is saving crawl effort, and pick noindex when your main goal is keeping the page out of results.

Can you use noindex and robots.txt together?

Not on the same URLs, at least not if you want the noindex to work. Google's documentation says a page must not be blocked by robots.txt for the noindex rule to take effect. If crawlers cannot fetch the page, they never see the tag. So you choose one method per path, based on what you need.

This trips up careful teams. Someone adds noindex to the share link template, and someone else adds a robots.txt disallow for the same folder to be safe. The two cancel out in a quiet way. Google cannot read the noindex, and the URLs can still be indexed from external links.

My rule is simple. For share links that should never appear in search, serve noindex and leave the path crawlable. For huge volumes of low value utility URLs where crawl load is the concern, disallow the path and accept that a few linked URLs might still show up in results.

How should you implement noindex on share links?

Google documents two ways to set noindex: as a meta tag in the page head, or as an HTTP response header called X-Robots-Tag. For share links, I prefer the header, because it can be applied at the server or edge layer to a whole route, and it also covers files like PDFs and exports.

The meta tag works well when your share pages are rendered from one template. Add the robots meta tag with noindex to that template and every share page inherits it. The risk is that a new template ships later without it, so I treat it like any other release check.

The header approach is harder to forget. If all share links live under one path, your engineering team can attach the X-Robots-Tag header to every response on that path. Exports and downloads get the same protection. Either way, write the rule down where your product and marketing teams can both see it, so nobody removes it during a redesign.

What about your marketing site on Webflow?

For most B2B SaaS companies, the marketing site and the product live on different systems. The marketing site might run on Webflow while the app and its share links run on your own stack, often on a subdomain. The guidance applies to the product side, and your marketing site rules should not leak across.

I check two things on every project. First, that the app subdomain has its own robots.txt and its own indexing rules, set by the product team on purpose. Second, that nothing on the marketing site links to user generated share pages as if they were public content. A testimonial that links to a customer's shared dashboard is a common example.

If your marketing site does host user submitted content, such as a community gallery or a template library, the same thinking applies there. Decide which items deserve to rank, and keep the rest out. I wrote about the Webflow side of this in how to control what gets indexed from Webflow.

How do you audit share links that may already be indexed?

Start by listing every URL pattern your product creates for sharing. Then search Google for your domain combined with each pattern, and check sample URLs in the URL Inspection tool in Google Search Console. If share pages are already indexed, add noindex, keep them crawlable, and let Google drop them as it recrawls.

The list of patterns is the slow part, and it is worth doing with an engineer. Share links hide in places marketing never looks, like invoice links, embed previews, and old feature flags. I usually find at least one pattern the team forgot existed.

Once you know the patterns, set an owner. Somebody should be responsible for checking that new features which create public URLs ship with an indexing decision. That one line in a release checklist prevents most of the problem.

Does this change how AI search treats your shared pages?

Google's guidance covers Google Search, so I would not assume it describes every AI crawler. Other answer engines and their crawlers publish their own rules, and they change. If your share pages hold customer data, the safest move is a login, because no robots rule protects content that anyone with a URL can read.

This is where I hold a firm opinion. Indexing rules are a courtesy system. They tell well behaved crawlers what you want. They do not protect private information. If a shared page would embarrass a customer when a stranger reads it, it should not be public at all, whatever the meta tags say.

For pages you do want AI engines to read and cite, the opposite logic applies. Make them crawlable, indexable, and clear. I covered the controls for how much of a page can be quoted in how nosnippet and max-snippet control AI previews.

What should you do next?

Make one decision this week: for each kind of shareable URL your product creates, choose search or no search. Then apply noindex or a login to everything in the no search group, and keep those paths crawlable so Google can see the rule. Put that decision in your release checklist so new features inherit it.

After 100+ projects for 25+ clients over 6+ years, the pattern I trust is that indexing problems almost never come from one big mistake. They come from small product features nobody thought of as pages. Google just gave you a clear reason to look.

If you want a second pair of eyes on what your product and marketing site expose to search, reach out at pravinkumar.co. I am happy to help you sort it out. Let's chat.