WordPress gets the most expensive part of agent readiness right by accident of age: it renders pages on the server in PHP, so the HTML a plain fetch receives is the page. Everything else about a WordPress site's score is decided by the plugin layer, the theme, and whatever sits in front of the origin. This guide describes what core does by default, what the plugin layer tends to add and break, the fixes in order of effort, and the one finding that is almost never WordPress's fault. The reference for core behaviour is developer.wordpress.org, and the plugin directory is at wordpress.org/plugins. This guide names categories of plugin, not products, because what matters is the mechanism each category adds to the page.
What core does by default
Server rendering is the default and, short of a theme that fetches its content in the browser, it stays the default. A7 compares the visible text in the raw HTML with the rendered DOM and pays five points for a ratio at or above 0.8; a classic or block theme passes without effort.
Core generates a robots.txt when no physical file exists, disallowing the admin path and, as of this writing, declaring a sitemap. Core has shipped its own XML sitemap since version 5.5, served as an index at /wp-sitemap.xml with child sitemaps per post type, and it can be disabled or replaced by a plugin. Core writes the <title> element from the site and page name. It does not, by default, write a meta description, Open Graph tags or JSON-LD; those are the job of the SEO plugin category, and B1, B2 and B4 between them carry thirteen points that depend on it.
Landmarks depend on the theme. The block themes shipped with recent versions use main, nav and footer elements in their templates; older classic themes vary, and B3 awards two of its four points only when every crawled page carries all three. Static files dropped into the web root are served by the web server before WordPress sees the request, which is what makes several of the cheap fixes below cheap.
What the plugin layer adds and breaks
The plugin layer is both the help and the harm, and the same site usually has both.
Help. An SEO plugin writes the description, the Open Graph set and a JSON-LD graph with Organization or WebSite on every page, and Article on posts, from one settings screen. That is the template-level approach structured data across templates argues for, and it is why a plain WordPress site can score well on pillar B with an hour's configuration. The same category usually offers a robots.txt editor and a sitemap with lastmod values, which D4 reads.
Harm, by category. A consent plugin adds a dialog whose markup is what A6 detects; the check looks for the class and id patterns consent tools share, scores one of two when the only marker is a cookie wall, and zero when a challenge or CAPTCHA marker appears as well. Cookie walls are interstitials explains the reasoning. A chat widget adds a script and an overlay on every page. A page builder wraps every block in several nested containers with inline styles and long class lists, which is the div soup B5 measures: script and style contents are already excluded from the denominator, so what remains is markup weight, and a builder-heavy page can sit below the 0.10 threshold on markup alone. Clean text ratio shows how to measure it yourself.
Two plugins doing the same job. Two SEO plugins, or an SEO plugin plus a schema plugin, can each write a JSON-LD block. B1 scores zero for any page where a block fails to parse, and two blocks that both claim to be the site's Organization with different names cost D5 its consistency point. One source per signal.
Slow origins. Uncached PHP on shared hosting can take longer to answer than the 1.5 second budget in A5. The scanner's timing for each probe is taken once the whole response body has been read, so a slow origin is charged in full rather than for its first byte. A page cache, whether a plugin or a server-level one, is the fix, and it is usually a checkbox.
The finding that is usually not WordPress
When a WordPress site fails A5 with a 403 to the three crawler probes, the cause is almost never WordPress. It is an edge in front of the origin, and most often it is Cloudflare's default AI crawler block, which refuses the request before robots.txt is read. A security plugin with a bot-blocking rule can produce the same result from inside WordPress, and the way to tell them apart is the response: a challenge page with the edge's markup in it is the edge, and a plain 403 with your theme's error page is the plugin. Either way the test is the same, fetch the homepage with a crawler's user agent and read the status code. The A5 evidence on the report records each probe's name, status and timing, and flags when the block contradicts your robots.txt.
Fixes, in order of effort
Low
Drop llms.txt and llms-full.txt in the web root; the server serves them as static files and A4 scores them on their contents, and ours shows the format. Create .well-known/security.txt the same way for D6, with a Contact field and an Expires date in the future. If the host's rewrite rules intercept dotted directories, a rewrite in the server configuration or a small plugin can serve it. Add Strict-Transport-Security in the server configuration or the host's control panel for D1; it is one line, and it lives in server configuration rather than in a theme. Confirm your robots.txt, whether physical or generated, does not block the six crawlers A2 names, and that it declares the sitemap. Configure the SEO plugin's description and Open Graph fields sitewide, and check the title template keeps every page between 15 and 70 characters.
Medium
Settle the structured data. One plugin emits the graph; fill in the organisation name, logo and sameAs profiles, and confirm the output parses with a validator, because JSON-LD that parses is a precondition for every other schema point. Replace the consent plugin with cookieless analytics if your jurisdiction allows it; if it does not, keep the banner and accept one of two on A6. Remove any chat or pop-up plugin you cannot justify. If your theme is missing a landmark, a child theme that wraps content in main and the menu in nav is a small change that pays on every page.
High
The High-effort work on WordPress is the page builder. Rebuilding a builder-based site in the block editor, or on a theme that emits lean markup, is the only way to move B5 substantially when the ratio is low on markup alone. Machine endpoints for C4 are possible, since core exposes a REST API, but the check looks for a link to API documentation, an OpenAPI spec or an MCP reference in the homepage HTML, so publishing a docs page and linking it from the footer is what earns the points.
What is not fixable without leaving the platform
Almost nothing on the page itself, which is the case for WordPress. What you cannot fix from inside WordPress is the edge in front of it: if the host or CDN blocks crawlers and offers no setting to change it, the A5 points are decided there. The other constraint is time, since a site built on a heavy builder can take longer to rebuild than to replace.
Check your own site
Run the free scan and read A5 first, because a 403 there makes every other line partial. Then compare the B1 and A6 evidence against what your plugins claim to be doing. The definitions are on the methodology page under discovery and access and understanding, and the three tiers of fixes maps the effort ratings above to what the work involves.