Google’s spam guidance is tightening around share pages

Google’s spam guidance is tightening around share pages

4 min read

Search Engine Journal reports that Google updated spam guidance around pages made for sharing, alongside restaurant ordering controls and AI Mode revenue notes. The practical SEO takeaway is simple: utility pages should not become indexable content factories.

TL;DR: If your site creates shareable utility pages at scale, treat indexing as a product decision, not a default.

What changed in Google’s spam guidance?

Search Engine Journal’s SEO Pulse, “Spam Guide Update, Restaurant Controls & AI Mode Revenue” by Matt G. Southern, reports that Google’s spam guide now adds indexing advice for pages made for sharing. That phrasing matters.

A lot of modern products create public pages as a feature. Saved itineraries. Restaurant menus. Shared carts. AI-generated summaries. Profile pages. Comparison pages. “Send this to a friend” pages. They are useful to a user in context, but that does not automatically make them good search pages.

That is the SEO trap. Product teams ship sharing because it helps growth. Then the pages get crawled. Then someone notices impressions in Search Console. Then the company starts treating every generated URL like an acquisition channel.

Google seems to be drawing a brighter line around that behavior, at least as Southern reports it. Pages built for user sharing can exist. The question is whether they deserve to be indexed.

I run Lucky Domains, where SEO and search visibility work often comes down to deciding which pages should rank and which should stay out of Google:

The practical test is boring, which is usually a good sign. If a stranger lands on the page from search, without the private context of the person who shared it, does the page fully answer a real query? If not, indexation is probably a liability.

a factory conveyor creating many small pages, with only a few passing through a search gate while the rest flow into a p

Why should builders care about “share pages” now?

Because AI makes this problem cheap to create.

Before generative AI, thin pages took effort. Now a workflow can spin up thousands of public URLs with summaries, recommendations, locations, snippets, tags, and rewritten copy. The pages look more complete than old doorway pages. They may even be useful in the original session. That does not mean they are search-worthy.

This is where SEO and AI product design are colliding. The more an app personalizes, summarizes, and packages content for sharing, the more it can accidentally create an indexable surface area that looks like scaled content. Google’s spam systems do not need to know your intent. They see patterns.

Southern’s roundup also mentions restaurant ordering controls and AI Mode revenue. Those are related in a broader way. Google is still absorbing more commercial and local tasks into its own surfaces, while also tightening expectations for sites that want organic visibility. Restaurants want control over ordering links. Publishers want clarity on AI Mode monetization. Product sites want traffic from pages that may not have been designed as landing pages.

The through line: Google is becoming less tolerant of accidental SEO. If a page is public, crawlable, and indexable, it is part of your search strategy whether your team admits it or not.

What should teams do before Google decides for them?

Start with an indexation audit, not a content rewrite. Pull every template type that can create public URLs. Sort them by user purpose: search landing page, account utility, sharing artifact, transaction support, internal navigation, partner page, AI output, archive.

Then make an explicit call. Index, noindex, canonicalize, block, consolidate, or improve. Do not leave it to defaults in the router.

For AI-generated or AI-assisted pages, add a second test. Is the page materially different from other pages on the site, and does it contain information a user could not get from a better canonical page? If the answer is no, the page probably should not be indexed. If the answer is yes, it still needs editorial standards, internal links, stable URLs, and a reason to exist beyond “our system generated it.”

I would also watch Search Console for weird growth in indexed pages that does not match intentional publishing. That is often the earliest sign that a sharing feature, filter state, or AI workflow has turned into a search liability.

Practitioner’s Take: If you build products with share links, saved views, AI summaries, or generated landing pages, add an “indexable?” field to the product spec. Not after launch. Before launch. The catch most teams miss is that noindex is not an SEO failure. Sometimes it is the cleanest way to keep a useful feature from becoming spam-shaped in Google’s eyes.