Campaign-page search visibility · 27 Oct 2026 · documentation review
Keep a campaign page public, retire it, or keep it private?
Choose the intended visitor state before choosing a search control. A URL that anyone can open, a URL absent from Google Search, and content that unauthenticated visitors cannot read are three different outcomes.
Choose the lasting site-side control
| Intended state | Control at the site | What a visitor can still do | First proof to retain |
|---|---|---|---|
| Public by direct link; excluded from Google Search For non-confidential content not meant for search discovery. | Keep a fetchable response, normally 200. Serve <meta name="robots" content="noindex"> in the HTML head or X-Robots-Tag: noindex in the HTTP response. Let Googlebot fetch that URL so it can see the directive. | Anyone with the link can still open and share the page. noindex is not privacy control. Other search engines may differ. | Logged-out final response and directive for each relevant URL variant; applicable robots.txt rule; later, the indexed URL Inspection state and last crawl. |
| Retired; no replacement exists | Remove the obsolete content and return a real 404 Not Found or 410 Gone, not an error message inside a 200. Remove stale internal links and sitemap entries as housekeeping. | The offer is no longer served at that URL. A prior Google result may remain until recrawl; an unrelated redirect is not a substitute for the missing page. | Logged-out final HTTP status for each relevant variant; later, indexed status and an exact-result check if disappearance is the claim. |
| Private from unauthenticated visitors For an embargoed or confidential offer. | Use existing CMS/server authentication or access control before exposure. Include assets and alternate URLs. Remove or correct any public copies already exposed. | A logged-out visitor must not retrieve the protected content. noindex, robots disallow and a Search Console request cannot protect an otherwise public page. | Logged-out tests of page, assets and variants showing content is unavailable; separately track Google state if already indexed. |
Google says a crawled noindex meta tag or header can remove a page from its results. A robots.txt disallow can prevent the crawler seeing that rule while a linked URL can still appear without crawled content. Do not use robots disallow as a substitute for, or layer it over, a crawlable noindex when the aim is to hide the result. Google: noindex · Google: robots.txt · Google: remove a page
Timing changes the sequence
- Already public and indexed: approve the intended lasting state and inventory exact result URLs, including case, query, host, protocol, redirect and asset variants. Apply the matching site-side control immediately. For confidential content, protect the content before waiting for a Search result change.
- Urgent Google suppression, when warranted: an owner of the relevant Search Console property can request a Temporary Removal for an exact URL or appropriately scoped prefix. Track request scope and status. Google describes processing as usually within a day, not guaranteed, and the block as lasting about six months; permanent site-side control remains necessary. It removes a Google result, not content from the internet. Search Console Removals help
- Not yet public: publish the crawlable
noindexresponse from the start if the page may remain public; keep an embargoed offer and assets behind access control or off the public site; do not create a public200for a page that should not exist. A Removals request is not a pre-publication privacy gate.
A canonical link expresses a preferred duplicate URL, not a de-indexing or confidentiality command. Removing a URL from a sitemap does not revoke a live page. URL Inspection’s live test checks current potential indexability, not whether Google’s stored result has been removed; “Request indexing” is a crawl request, not a guaranteed outcome. Google: canonical methods · Google: sitemaps · Google: URL Inspection
One exact-URL receipt
Use this record only for a page the operator is authorized to inspect. Keep the current site response and Google’s later state separate.
| Field | Record | What it can support |
|---|---|---|
| Decision scope | Approved intent, approver/time, requested and final URL, redirect chain, known case/query/host/protocol/asset variants, untested variants. | Which URLs and desired state the claim covers. |
| Ordinary logged-out response | UTC time and external vantage; final status and redirect; whether offer text is retrievable; returned/rendered HTML robots tag or HTTP X-Robots-Tag. For privacy, test the content itself without authentication. | What this checked variant serves now; not what Google has stored. |
| Googlebot access | Applicable robots.txt rule and method/time checked; live URL Inspection result when available. For noindex, check that Googlebot can fetch and see it. For privacy, confirm protected content is not exposed. | Current crawlability/indexability conditions; not a later indexed-result change. |
| Google’s later state | At each UTC check: Search Console property, exact inspected URL, indexed verdict, last crawl, indexing-allowed reason and Google-selected canonical if reported. Label live test separately. Check the exact Google result when result disappearance is the claim. | Whether Google has processed the intended state, subject to timing and result variation. |
| Urgent action, if any | Temporary Removals request time, URL or prefix scope, request ID/status and later status; separate lasting site-side control. | Request progress, not permanent removal or content protection. |
Stop at the supported claim. A verified response supports “this checked variant now serves noindex/404/410 or protects the offer.” It does not mean Google has caught up. If the last crawl predates the change, variants remain exposed, property access is unavailable or a request is merely submitted, record search state as pending or unknown and recheck. Even a Google result change says nothing about other search engines, copied pages, social cards or existing posts. URL Inspection · Removals help
Evidence limits and related checks
No page, Googlebot fetch, indexed state, Search Console request, removal, asset or social-card state was observed for this decision. No local fixture was built: syntax alone would not show whether Googlebot can reach an authorized URL or when Google updates its index. Before a real case, identify the approved intent, exact URL variants, current indexing state, CMS/server operator and Search Console property owner.
The page-correction receipt separates approval, deployment, public response and indexed copy. The share-card report keeps a native platform card separate from saved metadata. Neither is evidence that today’s three controls have been applied.