Google’s shared-page guidance: check Shopify app URLs

Google has updated its spam-prevention guidance for platforms that generate shareable pages and tools. For Shopify merchants and app developers, it is a useful prompt to inspect URLs created for a particular customer or conversation rather than public search discovery.

The 26 October documentation update adds advice about link-shared content and monitoring abuse. It does not announce a Shopify-specific requirement or a new ranking penalty.

Decide what each page is for

The revised guide asks platforms to distinguish public search content from pages intended for direct sharing, collaboration or utility. It recommends default indexing or crawling controls for the latter, alongside monitoring unexpected growth in public URLs.

Shared wishlists, saved carts, quote links and configurator results are examples worth checking in a Shopify app stack. These are our applications of the guidance, not a list of Shopify features Google has identified as problematic. A useful public buying guide and an individual customer’s saved configuration need not have the same policy.

Noindex and robots.txt do different jobs

Google’s noindex documentation explains that a supported meta tag or HTTP response header can keep a page out of its search results. Googlebot must be able to fetch the page to read the instruction.

A robots.txt block can prevent that fetch, leaving Google unable to see noindex. A blocked URL can still appear in results if Google discovers it elsewhere. Choose the control that matches the intended outcome instead of assuming more blocking rules are always better.

Neither a search instruction nor an obscure link is access control. If a quote contains confidential customer or pricing information, review authentication and authorisation separately with the app provider.

A small, testable audit

Choose a representative shared URL from each relevant app. Ask the provider who owns its response headers and page template, what indexing policy is applied, and whether merchants can intentionally opt a public page into discovery. Avoid a blanket change to every URL under an app path.

Use Search Console’s URL Inspection and Page Indexing reports to check what Google actually received. Keep a dated example before and after the change. For a page already in results, allow for recrawling rather than assuming a saved setting removes it immediately.

Monitor unexpected URL growth and investigate which feature or user activity created it. A spike is a reason to inspect, not proof that every new page is spam.

For broader search diagnostics, see our September spam-update checks. That earlier rollout is separate from this documentation change. Read the related guide.