WordPress already renders pages as plain, crawlable HTML and has shipped a built-in sitemap since version 5.5. What usually keeps ChatGPT, Claude or Perplexity from naming a WordPress site is not the CMS, it's a missing Organization entity, an SEO plugin's robots.txt rule, or a stray noindex setting left on from staging.
This is the install-path version of a wider question covered on what the Reflexa agent actually does on a site: the checks that find these issues run from outside, with no install needed, and the fixes themselves are the four reversible switches the agent applies once you turn them on.
Two things that matter most: it serves readable HTML without JavaScript, and it has shipped a sitemap by default since 2020. A default WordPress theme renders a post or page as server-side HTML, so a fetcher that doesn't execute JavaScript, which describes most AI crawlers, still gets the full text. WordPress 5.5 added a built-in XML sitemap index at /wp-sitemap.xml covering posts, pages, author archives and the homepage, with no plugin required.
Proof: WordPress Core — New XML sitemaps functionality in WordPress 5.5.
Why it matters: the two things that most often keep a site invisible to AI, a JavaScript-only body and no sitemap for discovery, are not problems a stock WordPress site has in the first place.
No, not by default. A fresh WordPress install's virtual robots.txt allows every user agent and simply points to the sitemap. The blocks that show up in practice almost always come from an SEO plugin's custom robots.txt rule, a security or firewall plugin's bot-blocking list, or a host-level setting added after the fact, not from WordPress core.
| Where an AI bot gets blocked on WordPress | What it looks like |
|---|---|
| SEO plugin's robots.txt editor | A manually added Disallow line naming GPTBot, ClaudeBot or PerplexityBot |
| Security or firewall plugin | A "block AI bots" or "block bad bots" toggle enabled under hosting protection |
| Host or CDN in front of WordPress | A bot-fight or challenge mode that answers verified AI fetchers with a challenge page |
| WordPress core itself | No block; the default virtual robots.txt allows all crawlers |
Do this: open yourdomain.com/robots.txt and read it literally, then confirm with the free AI crawler check, which tests the named user agents directly instead of only reading the text file.
Because nothing on the page states it in a form a model can parse with confidence. A theme's footer text ("© Acme Co.") is visible to a person but ambiguous to a model trying to resolve which entity owns the domain, which social profiles belong to it, and what it actually does. Organization JSON-LD with a sameAs list pointing to your real social profiles answers that in one structured block, the same pattern this very page uses for Reflexa itself.
Bottom line: a plain WordPress theme doesn't add this schema on its own. It has to come from a plugin, a theme that includes it, or a manual addition to the site's head.
Yes, and it's one of the most common accidents on WordPress. Settings → Reading has a checkbox labeled "discourage search engines from indexing this site," meant for sites still in development. It's routinely switched on during a staging build and never switched off after launch, and any crawler that honors the request, which includes the retrieval steps behind ChatGPT's search mode, Perplexity and AI Overviews, treats the live site the same as if it didn't exist.
Why it matters: this single checkbox can undo every other fix on this page. Check it before anything else, with the noindex check or by viewing the page source for a noindex meta tag.
It can be, though indirectly. A crawler that requests a page and times out before the server responds comes away with nothing to read or cite, no matter how good the content is once it finally loads. Cheap shared hosting with no page caching is the usual cause on WordPress specifically, since every uncached request has to run the full PHP page-build process from scratch.
Do this: turn on page caching, host on a plan built for WordPress rather than generic shared hosting, and check what a fetcher actually receives with what AI sees.
None of this requires buying anything, and most of it is a settings screen:
Bottom line: on WordPress, the gap between invisible and recommended is almost always a settings screen and a block of schema, not a rebuild.
No, a stock WordPress install allows every crawler. The blocks that show up in practice come from an SEO plugin's custom robots.txt rule, a security plugin's bot-blocking setting, or a host's firewall, none of which is WordPress core behavior.
It needs something that states plainly who runs the site, and Organization JSON-LD is the clearest machine-readable way to do that. Without it, or without a matching About page, an engine has to guess at your entity from scattered mentions instead of reading one clear answer.
Yes. That checkbox in Settings → Reading asks crawlers to skip the whole site, and it is commonly left on by accident after a staging copy goes live. Any AI engine that respects the request treats your site the same as if it were offline.
It can be, indirectly: a crawler that times out before the page finishes loading comes away with nothing to cite. Cheap shared hosting is the most common cause, and caching or a faster host fixes it without touching the content.
No. Every fix here is a settings screen, a plugin option or a plugin upload, not a code change. The Reflexa WordPress plugin applies the schema, crawler-access and discovery-file fixes from inside the dashboard, with no FTP and no theme file to open.
The free check reads your site the way ChatGPT, Claude and Perplexity read it, no install and no card. 3 minutes, evidence included.