Turn WordPress publishing into citation-ready knowledge.
Find plugin conflicts, duplicate schema, archive noise, rendering gaps and stale content before they weaken answer-engine discovery.
Five checks before content optimization begins.
Fix access, duplication and rendering problems before interpreting weak AI visibility as a content-only issue.
How these things actually work on WordPress
Generic advice stops being useful at the point where you have to click something. Each row below is the mechanism on this platform, linked to the vendor documentation it came from.
| robots.txt | WordPress serves a virtual robots.txt from do_robots(), whose default is User-agent: *, Disallow: /wp-admin/, Allow: /wp-admin/admin-ajax.php plus a Sitemap line. It is filterable through the robots_txt filter. On a standard nginx or Apache config a real file in the web root is served before WordPress ever runs, so uploading robots.txt overrides the virtual one. Platform documentation |
|---|---|
| Structured data | Core emits no schema.org markup for content and offers no structured-data API. Everything comes from the theme, an SEO plugin, a dedicated schema plugin, or your own JSON-LD echoed on the wp_head hook. Because several plugins can each emit their own graph, duplicated or conflicting Organization and Article nodes are the normal failure here, not missing markup. Platform documentation |
| Sitemap | Since WordPress 5.5 a sitemap index is generated at /wp-sitemap.xml covering public post types, taxonomies, author archives and the homepage. It is customisable through wp_sitemaps_post_types, wp_sitemaps_taxonomies and related filters, and can be disabled with wp_sitemaps_enabled. Most SEO plugins replace it with their own at a different URL, so two sitemaps often coexist. Platform documentation |
| /llms.txt | On self-hosted WordPress this needs no workaround: upload llms.txt to the document root. The recommended server config serves existing files before routing to index.php, so the static file wins. This does not apply to WordPress.com hosted plans, where filesystem access is restricted. Platform documentation |
| Rendering | Classic and block themes both render on the server and hand a non-JS crawler complete HTML. The risks are plugin-shaped: lazy-load scripts that replace image sources, load-more listings, builder-injected tabs and accordions, and full-page caches that vary by cookie. A headless front end is the case where key content is genuinely client-rendered. Platform documentation |
| The gotcha | Settings, Reading, "Discourage search engines from indexing this site" does more than emit a noindex tag: it also disables core XML sitemaps, so /wp-sitemap.xml starts returning 404. A staging site promoted to production with that box still ticked loses its sitemap silently, and an SEO plugin that has replaced the sitemap URL will not warn you. Platform documentation |
Do these three first
- Open Settings, Reading and confirm the "discourage search engines" box is unticked, then load /wp-sitemap.xml and /robots.txt to confirm both respond. ↗
- Upload llms.txt to the document root over SFTP and verify it returns 200 rather than being swallowed by the index.php rewrite. ↗
- View source on one post and count the Organization nodes: there must be exactly one. Disable whichever plugin emits the duplicate. ↗
Check implementation decisions against current WordPress documentation.
WordPress documentation ↗A practical WordPress GEO workflow.
Separate technical readiness, content evidence and continuous measurement.
Start with checks that do not consume AI tokens.
Questions teams ask before they start
Does a platform page mean InsightWonder edits the site automatically?
No. The page explains platform-specific checks and implementation paths. Write-back or app-based changes should be described only where a verified integration exists.
Are robots.txt and llms.txt enough for GEO?
No. They help with access and orientation, but useful answers still depend on clear content, structured evidence and credible external signals.
Should platform pages be published before examples exist?
No. Publish only after the page has platform-specific checks, executable steps and a real or complete example.
Does InsightWonder modify theme or template code?
No. Platform integrations use supported extension points rather than editing theme files directly.
Is a technical fix enough to get recommended?
Rarely. Access checks remove blockers, but whether a model names you still depends on clear content, structured evidence and credible external signals.
Can more than one site be connected?
Yes. Sites are separate measurement scopes under one account, so results stay comparable instead of being mixed together.
Turn AI visibility into a repeatable growth system.
Create a project, confirm your market and start measuring the questions that matter.