AEO for WordPress: Getting a WordPress Site Fetched, Parsed and Cited by AI Assistants

Updated October 2026 · Written and maintained by the Progression Agency strategy team

AEO for WordPress is answer engine optimization applied to the WordPress stack: the robots.txt rules, firewall and CDN settings, caching, rendering, structured data, sitemaps and page structure that decide whether ChatGPT, Claude, Perplexity, Gemini, Microsoft Copilot and Google AI Overviews can fetch a page, parse it and cite it. It is for businesses, publishers and WooCommerce stores whose site runs on WordPress and who want to be named when a buyer asks an assistant instead of a search box. The output is a site that documented AI crawlers can reach, pages whose answers sit in the HTML, and a monthly record of which prompts name you. Progression Agency is based in New York City and takes on WordPress AEO work for clients across the United States and worldwide.

What is AEO for WordPress?

AEO for WordPress is the platform half of answer engine optimization: making sure the software that sits between your content and a crawler (WordPress core, the theme, plugins, the page cache, the host and any CDN) lets AI assistants in and hands them the complete page a person would see. Answer engine optimization as a whole also covers what you write and who corroborates it; this page stays on the part that only applies when the site is built on WordPress.

An assistant can only cite what it can fetch and read. Before any judgment about quality, a request for one of your URLs has to pass a chain of WordPress-specific gates, and each gate is controlled by a different plugin, setting or vendor. Many WordPress sites have never had that chain checked from the outside, because every gate looks open from a logged-in browser.

How it differs from WordPress SEO

WordPress SEO configures the site for Google and Bing rankings: the SEO plugin, permalinks, archives, Core Web Vitals and migrations. Our WordPress SEO services page covers that work and this page does not repeat it. The AEO layer adds three questions an SEO plugin does not ask: which AI user agents are being refused by something other than robots.txt, whether the answer text survives without JavaScript, and whether the facts an assistant would quote are stated once, as text, where a parser can find them.

The six control points

Six places on a WordPress site decide whether an assistant can use a page. They are worth naming because each has a different owner in most organizations: marketing owns the SEO plugin, a developer owns the theme, and the host or an IT contact owns the firewall.

How do buyers and WordPress site owners phrase prompts to AI assistants?

Two groups ask assistants questions that a WordPress site has to be ready for. Your customers ask about what you sell, in full sentences with constraints attached. Site owners and their developers ask about the platform itself, usually after noticing that a competitor is named in an answer and they are not.

Measured search demand for the platform questions is small, and it is phrased around tools instead of outcomes. Site owners look for a plugin; what they need is a check of the whole chain.

What these prompts have in common

None of them is a keyword. Each describes a situation, and the assistant assembles its reply from several sources at once. A WordPress site earns a place in that reply by stating specific facts (a price range, a service area, a version number, a policy) in a form that can be lifted out as a sentence. Our guide to ranking in ChatGPT explains how answers are assembled; the sections below cover what WordPress has to do so your pages are candidates at all.

Which AI crawlers request a WordPress site, and what does each one control?

Each assistant vendor documents its own user agents, and most run more than one: a crawler that builds a search index, a crawler that collects training data, and a fetcher that runs when a user asks about a specific page. They are separate decisions, and a WordPress site can allow one and refuse another.

Search, training and user-triggered fetches are three decisions

OpenAI states that its settings are independent: a site can allow OAI-SearchBot so that it appears in ChatGPT search while disallowing GPTBot to keep content out of training. Anthropic and Apple draw the same line with their own tokens. For a business that sells something, the search crawlers are the ones to allow without hesitation; the training crawlers are a rights decision that belongs to whoever owns the content. Our LLM SEO page walks through that decision and the audit around it.

Why the firewall matters as much as robots.txt for these bots

The vendors’ own documentation points at the firewall. OpenAI recommends allowing OAI-SearchBot in robots.txt and also allowing requests from its published IP ranges. Perplexity publishes allow-rule instructions for Cloudflare and AWS firewalls that combine the user agent with its IP list. Anthropic warns that blocking its IP addresses is not a reliable opt-out, because it stops the bots from reading robots.txt in the first place, and says its bots will not try to get past a CAPTCHA. On WordPress, where security plugins and CDN bot settings are common, this is where access is often lost.

robots.txt on WordPress: where does the file actually come from?

On a default WordPress install there is no robots.txt file on disk. WordPress generates one on request, and at least four other things can change what a crawler finally receives. Knowing which one is in control is the first job, because editing the wrong one changes nothing.

WordPress core answers a request for /robots.txt with the do_robots() function, which outputs one group for all user agents that disallows /wp-admin/ and allows /wp-admin/admin-ajax.php; since version 5.5 the output also points to the core sitemap. That default names no AI crawler and blocks none. Plugins alter the output through the robots_txt filter, and the whole mechanism only runs when WordPress sits in the site root and no physical file exists.

Five places a WordPress robots rule can come from

• WordPress core. The generated default described above: safe, and silent about AI crawlers.
• An SEO plugin. Yoast SEO and Rank Math each provide a robots.txt editor in the dashboard; Rank Math’s edits the virtual file and asks you to delete any physical file first.
• A physical file. A robots.txt uploaded to the web root, often years ago by a previous developer, is served in place of the generated one.
• The hosting platform. On WordPress.com, the Prevent third-party sharing setting adds known AI bots to the disallow list.
• The CDN. Cloudflare’s managed robots.txt places its own rules, including disallow groups for named AI crawlers, ahead of whatever the origin serves.

The only version that counts is the one a crawler receives at your public /robots.txt address. Fetch it from outside the site, not from a dashboard preview, and read it top to bottom. The format is standardized as RFC 9309: a crawler obeys the group that names it and falls back to the wildcard group only when none does, so a short allow group for one bot is not cancelled by a broad rule elsewhere in the file.

A pattern that separates search from training

A WordPress site that wants to be cited but does not want its content used for model training can say so in a few lines. The choice is a business decision; the syntax is simple.

• Name OAI-SearchBot, Claude-SearchBot and PerplexityBot in their own groups with Allow: /.
• Name GPTBot and ClaudeBot with Disallow: / if training use is not wanted, and treat Google-Extended and Applebot-Extended the same way.
• Keep the wildcard group for all other agents, including the /wp-admin/ rule and the admin-ajax exception that themes and plugins rely on.
• Keep the Sitemap line, and make sure it points to the sitemap index the site really serves.
• Repeat the file on every subdomain; Anthropic’s documentation notes that an opt-out has to be made per subdomain.
• Allow time: OpenAI says its search systems can take about 24 hours to adjust after a robots.txt change.

The “Discourage search engines” checkbox

Settings, Reading contains one box that can undo everything else. According to the WordPress documentation for the Reading screen, since version 5.3 it adds a noindex, nofollow robots meta tag to every page instead of a robots.txt rule; the robots API introduced in 5.7 keeps that behavior. Leaving the box ticked after a staging site goes live is a common launch-day mistake. A noindexed page leaves Google’s index, and Google states that a page must be indexed and eligible for a snippet before it can be a supporting link in AI Overviews or AI Mode.

Security plugins, host firewalls and CDNs: where do AI crawlers get blocked by accident?

A robots.txt rule is a request; a firewall rule is a locked door. On WordPress the door is typically locked by a security plugin, a managed host’s bot protection or a CDN setting that someone enabled to stop scrapers, and the lock applies to the AI search crawlers you want as well.

Cloudflare’s AI bot settings

Cloudflare sorts AI traffic into three behaviors: Search, Agent and Training. Each can be allowed, blocked everywhere or blocked only on pages that show ads. Its documentation states that from September 15, 2026 new domains default to blocking Training and Agent bots on pages that display ads while Search stays allowed, and that crawlers used for both search and training are caught by every option that blocks training. If your WordPress site moved onto Cloudflare recently, or someone once switched on the older “Block AI bots” option, check which crawlers are affected. AI Crawl Control shows which AI services are requesting the site and lets you set a rule per crawler.

Bot challenges

Cloudflare’s Bot Fight Mode issues computationally expensive challenges to traffic it identifies as automated and, according to its documentation, cannot be adjusted with custom firewall rules. A challenge page is not your content. To a crawler it reads as an empty or irrelevant document, and Anthropic’s documentation is explicit that its bots do not attempt to pass CAPTCHAs.

Rate limits

Security plugins and hosts throttle clients that request many pages quickly, and a crawler that keeps receiving 429 or 503 responses gets little of the site. Anthropic’s bots support the Crawl-delay directive, which is a gentler tool than a block when server load is the real worry, and a page cache in front of WordPress removes most of the load problem at its source.

What a blocked crawler looks like from outside

Everything works in a browser. The home page loads, the SEO plugin shows green lights, and robots.txt looks permissive. The only evidence is in the logs: requests from an AI user agent answered with 403, 429, 503 or a challenge page. A test request that copies a bot’s user agent string is a useful first pass, but it does not come from the vendor’s IP ranges, so a pass is not proof. The access log is. Our free AI crawler access checker runs the first pass, and our technical SEO team reads the logs.

Rendering: is the answer in the HTML that WordPress sends?

WordPress builds pages on the server in PHP, which is good news: by default the text is in the HTML response. The exceptions are the parts of a page that a plugin or builder loads with JavaScript after the page arrives, and those are often the parts that hold the answer.

Googlebot renders JavaScript in a second pass, as its JavaScript SEO documentation describes. The crawler documentation from OpenAI, Anthropic and Perplexity explains what each bot is for and how to control it, and none of it promises to run a page’s scripts. Apple says Applebot may render pages and still advises that a site degrade gracefully when resources are unavailable. The safe working assumption is that the HTML response is all an assistant gets.

Blocks: static and dynamic

In the block editor, a static block saves its HTML into the database and a dynamic block is rendered by PHP on each request. Both arrive as HTML. Core’s Interactivity API, part of WordPress since 6.5 and used by the Search, Query, Navigation and File blocks, adds behavior on top of server-rendered markup instead of replacing it. A site built with core blocks and a block theme is, in rendering terms, about as safe as WordPress gets.

Page builders and bloat

Elementor, Divi, WPBakery and similar builders also output server-rendered HTML, so text placed in a standard text or heading widget is present in the response. The cost is weight: deep wrapper nesting and large stylesheets and scripts on every page, which slow the response a crawler is waiting for. The risk sits in particular widgets: tabs and accordions that fetch their panels on click, post grids with a “load more” button, sliders that hold the only copy of a headline, and reviews pulled in by a third-party script.

Where WordPress content goes missing

• Prices or specifications held in an image, a PDF or a slider.
• FAQ answers loaded by an accordion script, when the native Details block would keep the text in the HTML.
• Reviews and testimonials injected by a widget hosted on another domain.
• Product filters and post grids that swap their content through AJAX.
• Text inside an embedded iframe: maps, booking tools, forms and catalogs.
• Content shown only after a cookie banner or location prompt is answered.
• Pages behind a membership or login plugin.
• A headless front end that renders in the browser; our headless WordPress guide covers that case.

How to test a template

Request the URL without a browser, or open the page source instead of the inspector, and search for one sentence from each important section. Test one URL per template, not one page: a post, a page, a service or other custom post type, a category archive, a product and the home page. If the sentence is in the source, the template passes. If it only appears in the inspector, a script put it there.

Caching and performance: does every crawler get a fast, current page?

A page cache is the most useful performance layer on WordPress, and it changes what crawlers receive: a stored copy in place of a freshly built page. That is fine when the copy is current and complete, and a problem when it is not.

The WordPress caching documentation describes how plugins such as W3 Total Cache, WP Super Cache and Cache Enabler store posts and pages as static files so the server does far less work per request. Speed matters for AI retrieval because a fetch made while a person waits for an answer has little patience for a slow origin.

Stale copies

A cached page that still shows last season’s price, a closed location or an expired offer will be quoted as though it were current. Purge rules need to cover every page that depends on a changed fact: the service page when a price changes, category archives when a post is published, the home page when opening hours change.

Script-delay features

Optimization plugins can postpone JavaScript until a visitor scrolls or taps. A crawler does neither, so anything those scripts would have added (a pricing table, reviews, a tabbed specification) never exists for it. The fix is to move that content into the HTML, not to switch the optimization off.

Different pages for different visitors

Caches vary their output by cookie, device and sometimes user agent. Confirm that a crawler receives the same content as a first-time human visitor, and that a mobile variant does not drop sections the desktop page keeps.

Uncached pages deserve a look too: internal search results, filtered archives and cart pages are built fresh each time and are often slow. Keep crawlers out of them with robots rules and keep the cache warm on the pages that matter. Website speed optimization and a sound WordPress hosting setup do most of this work; website maintenance keeps it from drifting.

Structured data on WordPress: what should the markup say?

Structured data helps a machine confirm what a page is about and who published it; it does not replace the visible text. Google’s guide to optimizing for generative AI features says structured data is not required for generative AI search and that no special markup exists for it, while still recommending it as normal practice and asking that it match what the page shows.

On WordPress the markup usually comes from the SEO plugin. Yoast documents its schema output as one connected graph that other plugins can extend, and WooCommerce outputs product structured data automatically as JSON-LD on single product pages. Trouble starts when a theme, a review plugin and an SEO plugin each describe the same page differently. The WordPress SEO page covers removing duplicate graphs; the table below covers what the surviving graph should carry for assistants.

FAQ markup after Google retired the FAQ rich result

Google’s Search documentation changelog records that the FAQ rich result stopped appearing in Google Search on May 7, 2026 and that its documentation was removed the following month. FAQPage remains valid schema.org vocabulary, and a clearly marked question with its answer is still easy for any parser to lift. Add it because the page contains real questions, not in expectation of a search feature.

Check the markup against the page

Run important templates through the Schema.org validator and compare every value with the visible copy. Prices, opening hours, ratings and dates are where WordPress sites drift, because the visible figure is edited in the page and the marked-up one lives in a plugin setting. Our schema and copy validator automates that comparison, and the FAQ schema generator writes clean markup for hand-built sections.

llms.txt on WordPress: worth adding, not worth relying on

llms.txt is a proposed convention: a Markdown file at /llms.txt that gives language models a short description of a site and links to its most useful pages, ideally to clean Markdown versions of them. WordPress plugins can generate it with one switch. It is cheap to add and should not be mistaken for the work.

Which WordPress plugins generate it

Yoast SEO generates an llms.txt file as a free feature that selects key content automatically or lets you choose it. Rank Math has an LLMS Txt module that lists chosen post types with titles, URLs and short descriptions, and its own documentation notes that llms.txt is a proposal with limited adoption so far. To write the file by hand, our llms.txt generator produces one to upload.

What to list in a WordPress llms.txt

• The pages that define what the business does: services, products and pricing.
• The policies an assistant gets asked about: returns, shipping, warranties, service areas.
• The strongest guides and documentation, not every post in the archive.
• About and contact pages, so the business is described in your own words.
• Nothing that is noindexed, gated or thin.

What Google says about it

Google’s generative AI guide lists llms.txt among the things site owners can ignore for Google Search: the file neither helps nor harms visibility there, and Google adds that it is fine to maintain one for other systems that read it. That is the right weight to give it. Switch it on, keep it accurate, and spend the effort on access, rendering and content.

Sitemaps, feeds and the REST API: how do machines discover WordPress content?

Discovery is the quiet half of retrieval: a crawler has to learn that a URL exists before it can fetch it. WordPress ships three machine-readable routes to its content, and each deserves a short review.

XML sitemaps

Since version 5.5, WordPress core has published a sitemap index at /wp-sitemap.xml covering public post types, taxonomies, author archives and the home page, with up to 2,000 URLs per sitemap by default, and has referenced it from the generated robots.txt. SEO plugins such as Yoast SEO and Rank Math supply their own sitemaps instead. Whichever is active should list every indexable template and nothing that is noindexed, redirected or thin. The format is defined by the sitemaps.org protocol.

IndexNow

IndexNow lets a site notify participating search engines the moment a URL changes. The IndexNow plugin for WordPress, built by the Bing Webmaster team, submits new, updated and deleted URLs automatically and respects noindex settings. For assistants that answer from a search index, faster indexing shortens the gap between an edit and a correct answer.

Feeds and the REST API

WordPress exposes posts through RSS feeds and through the REST API, which serves public content as JSON and keeps private content behind authentication. Neither is a visibility lever in itself. They matter for two reasons: a security plugin that disables them can break legitimate integrations, and an API left at its defaults can list details you never meant to publish. Review both on purpose instead of by accident.

What does a WordPress site have to publish to be cited?

Once crawlers can reach and read the site, citations go to pages that state specific facts plainly. WordPress gives you good tools for that, and a few habits that work against it.

• One topic per URL: a page for each service, product line or location, built as Pages or a custom post type instead of sections of one long page.
• Question headings with the answer in the first two sentences beneath them.
• Prices, ranges, turnaround times and service areas as text, with the date they were last checked.
• Comparisons in the Table block, which outputs an HTML table; never a screenshot of a spreadsheet.
• FAQs in the Details block or under plain headings, so the text is in the response.
• An author page for each named writer, with credentials and links to profiles elsewhere.
• A real About page: who owns the business, where it operates and how to reach it.
• Policies as pages: returns, guarantees, cancellations and privacy.
• Links to primary sources for every figure you did not measure yourself.
• An honest “last updated” line that changes only when the content does.

The writing rules themselves are the same on any platform, and AEO content writing sets them out. What is particular to WordPress is where structure leaks away: tag and date archives that duplicate posts, builder sections that bury a heading inside a slider, and reusable blocks that paste the same paragraph onto thirty pages.

What sources do assistants cite for WordPress questions and WordPress-run businesses?

Assistants rarely answer from one page. For questions about WordPress itself they lean on official documentation and long-standing community sources; for questions about a business that happens to run on WordPress they combine the site with third-party profiles that confirm it. The table lists where to be present and accurate. It describes tendencies, not measured shares.

Corroboration is slower than configuration and no plugin automates it. Local AEO covers the profile side for businesses with a service area, and AEO for small business covers what an owner can do before spending anything.

How is AI retrievability checked on a WordPress site?

With requests, logs and source code, not with a plugin score. The checks below take about a working day on a typical business site and produce evidence a developer can act on.

1. Fetch the public /robots.txt and identify which of the five sources produced it.
2. Request the home page and one URL per template with each documented AI user agent; record the status code and response size.
3. Pull 30 to 90 days of access logs from the host and filter for the AI user agents: which arrived, what they requested and what they were served.
4. Compare the IP addresses of those requests with the ranges OpenAI, Anthropic and Perplexity publish, to separate real crawlers from imitators.
5. Review CDN and security plugin settings for AI bot blocking, bot challenges and rate limits.
6. Open the source of each template and search for the sentences that carry the answer.
7. Load the same URLs as a first-time visitor and as a crawler, and compare the cached output.
8. Validate the structured data on each template and compare it with the visible copy.
9. Open the sitemap index and compare its URLs with the pages that should be indexed.
10. If /llms.txt exists, confirm it is current and that every link in it resolves.
11. Confirm indexing of the same templates in Google Search Console and Bing Webmaster Tools.

We run this as a fixed-scope AEO audit; the AI visibility audit adds the prompt-set baseline, and a full SEO audit covers the ranking side of the same site.

How are results measured?

In two layers that move at different speeds. Technical measures (crawler requests, status codes, render completeness) change within days of a fix and are certain. Visibility measures (whether an assistant names or links you) change over weeks and are probabilistic, because answers vary from one run to the next.

Be wary of any WordPress plugin or dashboard that reports a single “AI visibility score”. Google’s guide points out that no third-party tool has access to its internal systems, and the same is true of every other assistant. Our free AI visibility checker runs a first prompt test, the prompt builder helps write the set, and our comparison of AI visibility trackers covers the paid tools.

What does a WordPress AEO engagement include?

An audit that proves what crawlers receive, fixes made inside the WordPress installation you already have, content and schema work on the pages most likely to be cited, and monthly measurement. The scope is written down before work starts.

The audit

• Crawler access report: status codes per AI user agent, per template, with log evidence.
• Render report: what each template contains without JavaScript.
• Schema reconciliation: every marked-up value compared with the visible page.
• Discovery review: sitemap, robots.txt source, llms.txt, indexing status.
• Prompt-set baseline: the buyer prompts, who is named today and which sources are cited.

Fixes inside WordPress

• robots.txt rewritten at its real source, with search and training crawlers handled separately.
• Firewall, CDN and security plugin rules adjusted so documented AI search crawlers are allowed.
• Cache purge rules and script-delay exclusions set for pages that carry changing facts.
• Script-loaded content rebuilt with blocks or server-side templates.
• One schema graph, with duplicates from themes and add-on plugins switched off.

Content and corroboration

• Priority service, product and policy pages restructured so each section answers its heading first.
• New pages where a prompt has no page to cite: pricing, comparisons, service areas.
• Author, About and contact pages completed.
• Business profiles and directory listings corrected to match the site.

Monitoring

The prompt set is repeated every month, crawler logs are re-read, and templates are re-tested after theme and plugin updates, since an update can quietly undo a fix. Where development work is larger than a fix, our WordPress development team takes it on, and a WordPress maintenance plan keeps the stack patched in between.

One service, several names: what do WordPress site owners search for?

The work on this page is sold as AEO, GEO, AI SEO, LLM SEO and half a dozen other labels, and they overlap almost entirely. If you arrived by searching one of the phrases below, this is the page for it.

AEO vs GEO vs LLM SEO explains where the terms differ; our generative engine optimization page and our AI SEO agency page describe the same team from those angles.

How much does AEO for WordPress cost?

Most WordPress AEO work is priced as a one-off audit followed by a short fix project or a monthly retainer. The figures below are the planning ranges Progression Agency publishes; a quote follows a written scope, and the number moves with template count, how much is rendered by scripts, and how many plugins touch the same output.

Tracking tools are a separate and smaller line: the AI visibility trackers we have verified list at $20 to $295 a month. AEO pricing breaks the bands down, and the marketing agency pricing guide sets them beside other services.

How long does AEO take on a WordPress site?

Access and rendering fixes are quick; citations are not instant. We plan the technical work across the first month and judge visibility at about ninety days, against a baseline taken before anything changes.

Some of the waiting is set by the vendors. OpenAI says its search systems can take roughly a day to act on a robots.txt change. Google’s AI features documentation says recrawling can take anywhere from several days to several months, depending on the page. Nothing shortens those waits except starting them early, which is why crawler access is fixed before any content is rewritten. How long AEO takes goes through the stages in more detail.

How do you choose an AEO provider for a WordPress site?

Ask for evidence, WordPress-specific answers and a written scope. A provider who cannot say where your robots.txt comes from has not looked at your site.

WordPress.com, WooCommerce, multisite and headless: where do the rules change?

The checks above assume a self-hosted WordPress site with a conventional theme. Four common setups move the gates to a different owner.

WordPress.com

On WordPress.com the hosting, caching and firewall belong to the platform. The setting to know is Prevent third-party sharing: WordPress.com says ticking it removes the site from its network of content partners and adds known AI bots to the robots.txt disallow list. A business that wants to be cited should understand that this box asks AI crawlers to stay away.

WooCommerce stores

WooCommerce prints product markup on single product pages by default, and its documentation is clear that marked-up data should already be visible on the page. For AI shopping answers the product record matters as much as the page: complete attributes, variation data, stock status and identifiers. Google’s generative AI guide points merchants to Merchant Center feeds for product visibility in AI responses. Shopify vs WooCommerce compares the two platforms, WooCommerce hosting covers performance, and AEO for ecommerce covers product data in depth.

Multisite and subdomains

Each site in a network, and each subdomain, answers for its own robots.txt, sitemap and schema. Rules set on the main site do not cover blog.example.com or shop.example.com, and a network-activated security plugin can block crawlers everywhere at once.

Headless WordPress

When WordPress only supplies content through its API and a JavaScript framework builds the pages, rendering stops being WordPress’s job. The front end has to render on the server, and it has to produce its own robots.txt, sitemap and structured data.

AI agents inside WordPress

A separate development is worth knowing about. WordPress 6.9 introduced the Abilities API, a registry of what a site can do, and the WordPress AI team’s MCP Adapter exposes selected abilities to assistants such as Claude and ChatGPT as tools. That concerns assistants operating a site with permission, not being cited by one, and it does not change the retrieval work on this page. It does show that WordPress is being prepared for agents as well as crawlers.

Related services

Pages that sit beside this one, starting with its SEO twin.

• WordPress SEO services: plugin setup, technical fixes, WooCommerce SEO and migrations.
• Answer engine optimization agency: the full AEO service, on any platform.
• LLM SEO: the technical audit behind AI retrieval.
• How to rank in ChatGPT: the steps from crawler access to citation.
• Technical SEO agency: audits, rendering and site architecture.
• Website maintenance: updates, backups and monitoring.
• AEO for small business: where to start and what to do for free.
• WordPress development: themes, blocks and custom builds.
• WordPress maintenance services: plans and pricing.
• Website migration services: moving hosts or platforms without losing visibility.
• Enterprise AEO: large sites and multisite networks.
• AEO for SaaS and AEO for B2B: two markets that often run on WordPress.
• AEO by industry: every market page in one index.
• Webflow vs WordPress: if a platform change is on the table.

Frequently asked questions