Skip to content

Fix an accidental noindex block on a landing page

Repair an accidental noindex block on a public landing page with a copyable change record, live inspection checks, and a clear recovery procedure.

RunbookOctober 8, 20264 min read
~/runbook $ cat writing-seo.md[guide]
>_// Writing & SEO
67 lines · writing-seo.md0x4db4

This sheet contains partner links. A purchase through one earns Runbook a commission at no additional cost to you. How we make money.

A landing page can load correctly for customers while telling Google to exclude it from search. If the page should attract organic visitors, check for an accidental noindex rule before rewriting its copy or requesting indexing again.

Google can receive that instruction through an HTML meta tag or an X-Robots-Tag response header. Both can prevent indexing. Google’s noindex documentation explains the two mechanisms.

This workflow repairs one approved public HTML page. It does not apply to intentionally excluded campaign variants, private pages or staging environments.

Method: Based on current documentation and editorial analysis. Not a hands-on product test. Sources were checked on October 8, 2026. This covers the documented Search Console web interface, with no CMS-specific version assumed.

Prepare access and boundaries

You need permission to change the page’s indexing settings, someone who can inspect its hosting rules, and owner or full-user access to the relevant Search Console property to request indexing. Google documents that permission requirement in its recrawl guide.

Choose the exact production URL. Confirm with its owner that it should appear in search. Save the current page setting and any applicable server rule. Also select one intentionally excluded page as a control: it must remain excluded after your repair.

Capture the failure before changing anything

Enter the full URL in Search Console’s inspection bar. Record the last crawl date and reported exclusion reason. Then select Test live URL. The initial inspection describes Google’s stored version; the live test checks the current page. Google’s URL Inspection guide distinguishes these views.

If the live test already allows indexing, investigate the difference in timestamps before making another change. An older report is not evidence that today’s fix failed.

If the URL redirects elsewhere, first confirm which address should be indexed. For a retired Shopify campaign address, use the campaign redirect workflow.

Remove the rule at its source

Have the page maintainer inspect both the delivered HTML and HTTP response headers. Look for robots or googlebot meta tags containing noindex, and applicable X-Robots-Tag headers containing noindex or none.

Remove the accidental indexing restriction from the responsible page setting, template or hosting rule. Preserve unrelated directives. Adding an allowance alongside a remaining restriction is insufficient: Google applies the more restrictive conflicting rule, and none includes noindex. Google’s robots specifications document this behavior.

Make the smallest change that covers the approved URL. If a shared template caused the problem, identify its affected pages before changing it globally. Use your platform’s documented cache refresh procedure if an old response persists.

Do not block crawling to solve this problem. Google must fetch the page to read its indexing instructions. Google’s noindex guidance explains why a robots.txt block prevents that inspection.

Keep a repair record

Copy this hypothetical example into your change ticket. Replace the example values and fill observations only after checking them.

Case: hypothetical autumn consultation page
Target: https://example.com/autumn-consultation
Approved intent: public, eligible for organic search
Control: https://example.com/campaign-variant
Control intent: intentionally excluded
Owner: [name]
CMS/template version or release: [record]
Previous setting/rule: [attach exact saved value]
Last Google crawl and exclusion: [record]
Live test before change: [record]
Responsible layer: [page / template / server / CDN]
Exact change and time: [record]
Target live checks after change: [record]
Control exclusion after change: [record]
Indexing request time: [record only if submitted]
Later crawl and index status: [record]
Rollback location and owner: [record]

Verify, replay and recover

Repeat the live inspection. Expected technical output is Crawl allowed? Yes, Page fetch: Successful, and Indexing allowed? Yes, with the intended page content visible. Treat these as a combined check: Google warns that an indexing allowance alone can be misleading when robots.txt blocks crawling. The live test also cannot predict Google’s eventual canonical selection. URL Inspection documentation

Confirm the control page still carries its intended exclusion. Our editorial acceptance rule is simple: close the technical repair only when the target passes and the control remains unchanged.

If the block persists, return to the delivered tags and headers; do not repeatedly toggle settings. If the change alters unrelated pages, restore the saved configuration, repeat both checks, and leave the target unresolved until a narrower repair is ready.

After a passing live test, request indexing once. Record acceptance separately from actual indexing. Google says crawling can take days to weeks, repeated requests do not accelerate it, and inclusion is not guaranteed. Recrawl guidance

At a later review, compare the new crawl date and stored index status. A clean live test proves the checked technical conditions changed. Search visibility remains a separate outcome.

About Runbook

AI tools and automation builds for marketers. What to use, how to wire it, and the workflow to copy this week. How we work

GET THE NEXT DISPATCH

Run the next build before your competitors read about it.

One short email when an AI tool or automation actually changes the work, with the build to copy.

No send unless there is a build worth running.

// keep_reading

Related builds