Websites and search
Choose which customer pages belong in search
Google has updated its guidance on shared and generated pages. Decide what belongs in search, what needs noindex and what should require customer sign-in.
A photographer sends a customer a gallery link to choose their favourite portraits. The studio also has a public portfolio that helps new customers decide whether to book. Both contain photographs, but they serve different audiences. The website should reflect that difference when it decides who can open a page and whether it belongs in search.
What changed this week?
On 26 October, Google updated its guidance on preventing user-generated spam. We reviewed the update on 27 October. The change is relevant to businesses whose websites create shareable pages, reports or other outputs, as well as platforms that let users publish content.
Google has clarified guidance for content shared by link
Google's update log says the revised guide adds advice on keeping link-shared content out of the index and monitoring abuse in Search Console. This is a documentation update, not an announcement that every shared page is spam or that a new ranking penalty has been introduced.
Google Search Central: 26 October documentation update26 October 2026
The intended audience should guide publication settings
The revised guide asks site owners to consider whether user-created pages, generated outputs and interactive tools are intended for search discovery or direct sharing. It also recommends monitoring unexpected growth in indexed pages and search queries that do not fit the site's purpose.
For a small business, our interpretation is that the publication settings deserve attention when a new feature starts generating URLs. A useful customer tool does not necessarily need a separate searchable page for every result it produces.
Google: Prevent user-generated spam on your siteUpdated 26 October 2026
What could this mean for a small business?
Consider an illustrative portrait studio. Its public pages explain session options, show approved work and answer booking questions. A customer gallery lets one client review a particular session. A draft gallery lets the photographer check the selection before sending it. These are examples, not findings from a client website.
The public portfolio has a clear discovery purpose. The customer gallery needs a deliberate sharing policy. The unfinished draft should not become public just because the software has created an address for it.
The same review can apply to an online quote, a personalised recommendation or an AI-generated report. Ask what the page contains, who needs it and whether the recipient should be able to forward it. Then choose access and indexing settings that match those answers.
Avoid treating a long or unfamiliar URL as proof that a page is private. In the studio example, the owner should test the customer journey using a separate browser session, then check whether the same access rules apply to downloadable photographs and other files.
Search visibility and access control are different
Google's existing guidance says confidential or private content should be password protected so that only authorised users can access it. It separately describes noindex as a way to keep content out of search results.
Our practical recommendation is to use a proper sign-in or other appropriate access control for customer work that must stay restricted. Keep the search setting as a separate decision. Hiding a result from Google is not a substitute for checking who can open it.
Google: Control what you share with Google SearchExisting guidance; reviewed 27 October 2026
Set the defaults before the number of pages grows
We suggest listing the kinds of pages your website creates, rather than starting with every individual URL. A studio might have service pages, portfolio entries, customer galleries and drafts. For each type, record the intended audience, who can publish it and whether it should be discoverable in search.
Make public publication an intentional step for customer-supplied or generated material. For example, a customer gallery could remain restricted while an approved selection is copied into a separate public portfolio entry. That gives the owner a clear point to check the content and its intended use.
If users can create public pages, assign someone to review reports of abuse and remove unwanted content. Begin with a manageable process for the volume you actually receive. A business with a few customer galleries has different needs from a platform accepting hundreds of public submissions each day.
Review the defaults again when adding a new tool, changing a website plugin or introducing an AI-generated output. Test what a visitor receives without signing in, which links appear publicly and whether the sitemap contains only the pages you intend to present for search discovery.
Ask your developer to check how noindex is delivered
Google supports noindex in a page's metadata or an HTTP response header. Its documentation says Googlebot must be able to crawl the resource to read the rule. Blocking that URL in robots.txt can stop Google from seeing noindex, and the URL can still appear in results if other pages link to it.
For a non-sensitive page that can remain accessible by link, ask your developer to verify the actual response and indexing rule. For private material, keep the access restriction in place. Do not make confidential content public just to let a crawler inspect a tag.
Google: Block Search indexing with noindexExisting guidance; reviewed 27 October 2026
What can you do this week?
Choose one feature that creates customer links. Use a sample with no real customer information for the first review.
- List the page types the feature creates, including drafts, final results and downloadable files. Write down the intended audience for each.
- Open a sample link in a signed-out browser and, where appropriate, with a different test account. Confirm that access matches the intended audience.
- Ask your developer to check indexing rules, public links and sitemap inclusion. Keep private-access checks separate from search settings.
- Review Search Console for unexpected indexed pages or unrelated queries. Investigate the actual URLs before changing settings across the whole site.
- Agree who can publish customer material, who handles abuse reports and when this review will be repeated. Record the settings so the next website change preserves them.
How Context Aware can help
We can review how a customer-facing feature creates and shares pages, check the relevant access and search settings, and help document a publishing process your team can follow. For a custom website or app, we can test the journey from draft to customer delivery and public publication.
A useful starting scope is one feature and a few representative pages. That can show whether the issue is a setting, a template or the way the feature was built, before you commit to wider changes.
A note on the research
We reviewed Hacker News, Apple, OpenAI, Anthropic and Google Search Central during topic selection. This article draws its release details and technical guidance from Google. X access was limited: OpenAI's profile returned an access error, and targeted searches did not provide an accessible current AI discussion we could verify. X reactions are not used as evidence.
Prepared by Context Aware with AI assistance and linked primary sources. Examples are illustrative. How we write our insights.