WordPress AI Search Visibility Checklist

By Abiot Y. Derbie - Founder, RankEcho - Updated 2026-09-12

# WordPress public-page launch worksheet

Version 1.0 — one public page, one reviewed correction

## Intent and boundaries
- Exact production URL, page owner, and launch date [required]:
- Why this page should be public; approved published status [required]:
- Draft, private, staging, and restricted routes to protect [required]:
- WordPress, PHP, theme, plugin, host, and CDN versions or owners:

## Saved setting and delivered output
- Settings → Reading checkbox before, save time, approver, and runtime blog_public value [required]:
- Signed-out GET before: final URL, status, headers, raw robots meta, canonical, and main text [required]:
- Core sitemap state and actual sitemap response for the page:
- Owner of each theme, plugin/code, host/CDN, or cache output:

## One correction and verification
- One approved change, implementation owner, and expected scope:
- Rollback operator, trigger, and saved setting to restore if public-intent review was wrong; preserve correct protection:
- Signed-out GET after: final URL, status, headers, raw meta, canonical, and main text [required]:
- Browser and independent cache/variant check:
- Actual sitemap response after; draft/private URLs absent where expected:
- Separate robots, rendering, index, query, referral, and conversion checks:

## Filled fictional HarborDesk example
- Intent: the published /harbordesk-exports-publish/ page should be public. Its draft and private siblings must keep their statuses and content.
- Setup on September 12, 2026: browser-only WordPress Playground scope clever-modern-state; WordPress 7.1, PHP 8.3.33, Twenty Twenty-Five 1.5; plugin, must-use, and drop-in lists were empty.
- Page text: “Fictional HarborDesk example: export a project as CSV from the project menu. Workspace owners can export completed tasks. Exports omit deleted tasks. Contact the workspace owner if export is unavailable.”
- Checked and saved: blog_public='0'; core sitemaps disabled; no posts sitemap provider registered. The public-page DOM showed noindex,nofollow, a self-canonical, title, and body.
- Reviewed correction: clear the sitewide checkbox and save. This reset the original public state, not a tested production rollback.
- Core after-state: blog_public='1'; core sitemaps enabled; the page provider included the published page and omitted the draft and private siblings. All three statuses and stored-content SHA values were unchanged.
- Separate function evidence: wp_robots() output max-image-preview:large. This was not captured from the after-state page.
- Real-site work remaining: signed-out GET, source, headers, canonical, body, browser, sitemap response, robots policy, production layers, and indexed state.
- No production, crawler, search, business-outcome, or rollback test ran.

Is this one WordPress page meant to be public?

Record the production URL and owner, then confirm the page is published and approved for public discovery. Preserve the status or access of drafts, private pages, staging sites, and restricted routes.

The Reading checkbox is sitewide. If exclusion is intentional, launch on the approved public environment. Send a directive affecting only this page to the noindex/canonical guide.

What does the WordPress Reading setting control?

In Settings → Reading, the checked box asks search engines not to index the site; it does not block visitors. Save Changes is required. For approved production pages, an unintended checked state is a sitewide launch blocker.

After any approved change, inspect what the site delivers. WordPress core behavior can be filtered, and the active theme must expose head output. A settings-screen state alone does not establish the public response.

What did the WordPress Playground test show?

On September 12, 2026, a browser-only Playground test used WordPress 7.1, PHP 8.3.33, Twenty Twenty-Five 1.5, and no listed plugins, must-use plugins, or drop-ins. Three fictional HarborDesk pages had published, draft, and private statuses.

With exclusion saved, blog_public was 0, core sitemaps were disabled, and the published-page DOM had noindex,nofollow, its self-canonical, and visible body. After clearing and saving, blog_public was 1; the core provider listed the published page, not its siblings. Statuses and stored-content hashes stayed unchanged.

After-state browser evaluation failed, so no page DOM, status, header, robots meta, or canonical was captured. The wp_robots() call and provider list are narrower evidence; no sitemap response or production delivery was tested. Resetting the original public setting did not test rollback.

Who owns the output when the setting and public page disagree?

Inventory the production theme, plugins, must-use plugins, drop-ins, code, host, CDN, and cache. Assign each directive, redirect, canonical, and sitemap behavior to its emitting layer. The empty Playground lists do not describe another installation.

Use the specialist guide for a mismatch. Robots.txt policy, JavaScript delivery, documentation, and product clarity remain separate tasks.

How do you verify the real public URL after one change?

Make one owner-approved correction. From a signed-out session, record the production request time, final URL, status, redirects, robots headers, raw meta, canonical, and main text. Repeat with the cache or variant identified. Do not infer delivery from wp_robots() or an admin screen.

Fetch the sitemap response; look for the published URL and confirm draft and private URLs are absent where expected. Presence supports discovery but does not prove indexing. Check robots policy and rendering through their existing owners, then inspect indexed state separately.

Record later search impressions and clicks, identified AI referrals, product actions, accounts, and customers as separate units. A saved setting, sitemap entry, indexed page, citation, visit, and conversion are not interchangeable, and sequence after launch does not establish cause.

Does WordPress need a special AI-search plugin or file?

For Google's AI search features, use ordinary Search foundations: index and snippet eligibility, useful text, and descriptive internal links. Google requires no special AI schema or text file. Its guidance does not establish another provider's requirements or promise an appearance.

This checklist concerns public discovery of a WordPress page. It does not install or evaluate an on-site AI search plugin for visitors searching within the website.

Where does RankEcho fit after the WordPress check?

The worksheet works without an account. The paid Fix Engine can organize a bounded correction for human review and manual shipment; it does not deploy WordPress, theme, plugin, host, or CDN changes, connect to Search Console, or request indexing.

Free audits check Perplexity and Gemini once per prompt. Paid and trialing accounts add ChatGPT, Claude, and Google AI Overviews when configured for the account, for up to 5 engines. RankEcho does not currently run Microsoft Copilot checks. RankEcho does not guarantee indexing, rankings, citations, traffic, or conversions.

Frequently asked questions

Sources reviewed

Material crawler-role and control claims below were checked against primary provider documentation and the robots standard. Access settings affect eligibility and reachability; they do not guarantee indexing, ranking, an AI impression, or a citation.