Keep staging and preview websites out of Google search

Decide whether the preview must be private

A staging site may contain unfinished copy, test forms, customer material or a future offer. If people should not be able to access it, use an appropriate authentication or access-control mechanism. A search setting does not make a publicly accessible page private. Keep an inventory of preview domains, temporary hosting addresses and old test sites. Record the owner, access policy and retirement date for each. An abandoned preview can remain discoverable long after the new website launches.

Keep readingPlan URL changes before launch

Understand the three different controls

Google's documentation distinguishes crawling rules from indexing rules and access protection. Choosing the wrong control can produce an unexpected result.

Google specifically warns that blocking crawling can prevent it from seeing a noindex instruction. A blocked URL may still appear based on links to it. Ask the developer to select controls that match the actual purpose and verify the response rather than assuming a file name proves the outcome.

• Authentication or password protection: restricts access to content that should be private.
• Noindex: tells a supported search crawler not to index an accessible resource when it can read the instruction.
• Robots.txt: controls which URLs a crawler may fetch; it is not a reliable mechanism for keeping every URL out of search results.

Test the preview from outside the signed-in session

A developer's browser may be authenticated automatically. Check what an ordinary unauthenticated request receives, including the actual temporary hostname. Look for exposed articles, assets, form endpoints and alternate preview URLs within the agreed scope. For an intentionally public preview using noindex, inspect the actual response and page instructions. For a private preview, confirm access is genuinely restricted. Do not describe a client portal as protected merely because a search engine is asked not to list it.

Make the launch switch a two-sided checklist

It is possible to protect staging correctly and still launch production with an accidental noindex instruction or authentication requirement. Review the real production domain as well as the preview configuration. Confirm the intended live URLs return the right content, have the correct canonical addresses and indexing instructions, and appear in the appropriate sitemap. Check forms use the intended live destination and test submissions are labelled. Keep protection on previews that remain in use after launch.

Worked example: the temporary domain appears in search

Imagine an old public preview is showing a service page under its temporary hostname. The owner verifies which URL Google has recorded and whether that page should still exist. The developer then applies the appropriate permanent access or indexing response to the preview, while checking the real domain remains eligible. Google Search Console's temporary removal tool is not a permanent access or indexing fix. Google says a successful temporary request lasts about six months. If removal is needed, use it only as part of the appropriate corrective process, with the underlying response addressed too.

Keep readingUse Search Console to check indexing

Keep evidence of the actual state

Record the preview host, test time, unauthenticated result and relevant response instructions. Separately record production checks and any later Google observation. Technical eligibility, a Google crawl and an indexed URL are different pieces of evidence. Repeat the launch checks when changing hosting, preview systems or site-wide SEO settings. Avoid deleting a useful production page simply because an old preview was exposed; fix the URL and environment that actually caused the problem.