Platform guide
WordPress AI readiness guide
WordPress already produces much of the structure crawlers and browser agents need. The work is making sure themes, plugins, caches, and security layers do not hide or contradict it.
1. Start with production access
In Settings > Reading, confirm that ?Discourage search engines from indexing this site? is off on production. Then inspect the public robots.txt file, not only the setting screen. SEO plugins, hosting tools, maintenance plugins, CDNs, and firewalls can each change what a crawler receives.
- The canonical HTTPS hostname returns the page without a login, challenge, or redirect loop.
- robots.txt expresses separate choices for search, user-requested access, and model development.
- Important pages do not accidentally send noindex in HTML or an X-Robots-Tag header.
- The CDN or WAF does not challenge legitimate documented crawlers indiscriminately.
2. Put the important answer in the HTML
A crawler should receive the page title, main heading, primary text, links, product or service facts, and contact route in the initial response. A visually complete page can still be nearly empty to a non-rendering fetcher when a theme or page builder inserts the content only after JavaScript runs.
View the page source and compare it with what appears in the browser. If the source contains only a shell, use server-rendered blocks or expose a reliable HTML version for the essential content.
3. Give every page one clear job
Identity
Use a descriptive title, one clear H1, an accurate description, and visible organization or author information.
Structure
Use headings in a meaningful hierarchy and native HTML for navigation, lists, tables, buttons, and forms.
Facts
Keep prices, availability, policies, dates, locations, and contact details visible and internally consistent.
Next action
Make the primary contact, booking, quote, purchase, or signup path easy to find and label it with a plain verb.
4. Add structured data that matches the page
Use an SEO or schema plugin to produce valid JSON-LD, then inspect the output. More schema is not automatically better: the type and properties should describe the visible page accurately.
- Organization or LocalBusiness for the operating identity and contact details.
- WebSite for the site identity and supported search action where appropriate.
- Article for editorial guides with an author and accurate publication dates.
- Product for WooCommerce products, including visible price, currency, and availability.
5. Keep discovery files accurate
Submit the XML sitemap produced by WordPress or the SEO plugin, keep canonical URLs consistent, and remove broken or redirected sitemap entries. An llms.txt file can be an optional summary, but it should not replace crawlable pages, sound navigation, structured data, or the sitemap.
6. Test actions, not only pages
A browser agent needs controls it can identify and operate. Give every field a visible label, use real buttons and links, keep validation messages specific, and make the complete flow usable by keyboard. Test search, contact, booking, cart, checkout, and policy discovery as applicable.
A membership, form, SEO, cache, or security plugin can help, but its name is not evidence that the public output works. Test the generated HTML, headers, files, and complete user journey.
WordPress launch checklist
- Confirm production indexing and crawler policy.
- Check raw HTML for the page?s essential content.
- Validate titles, headings, landmarks, links, and form labels.
- Validate JSON-LD against the visible facts.
- Submit and monitor the XML sitemap.
- Test the primary customer task from start to finish.
- Rescan after cache, theme, SEO, or firewall changes.