AEO inside an enterprise, where approval takes longer

The short answer: Inside an enterprise, the binding constraint on answer engine optimisation is not skill, it is queue time. Sort every finding by the approval it needs rather than by its size, ship the infrastructure and markup fixes that need no legal sign off first, and run the claims work on a slower track in parallel. In the enterprise engagements we have run, sequencing by queue got something shipped and observable sooner than sequencing by severity did. We have no published tally behind that, so read it as our experience rather than a measured result.
That sounds like project management advice. It is really a statement about how these systems read a site, and about which of your internal queues the engines are actually waiting on.
The clock you are racing is not the engine's
Small companies change a page on Tuesday and see what happens. A bank, an insurer or a twelve-division manufacturer changes a page in six weeks, because the page passes through brand, legal, regional marketing, and whoever owns the CMS release train. Nothing in that list is unreasonable. In the large organisations we have worked with, it meant the fix durations clustered at two ends: a set of things that shipped in days, and a set that shipped in quarters, with little in between. We cannot say that holds for every large organisation, only that we have not yet seen one where it did not.
A plan that ranks findings by impact alone ignores that shape. It hands over a list of fourteen, and the list stalls on item three because item three is a pricing claim and pricing claims go to legal. Meanwhile items seven, nine and eleven were a robots.txt line, a render fix and a schema property, none of which needed a lawyer at all.
The engines are not waiting politely while you resolve that. How long AEO takes to show up in answers covers the lag on the engine side. Add your internal lag to it and you can lose two quarters before anything is observable.
Sort findings by queue, not by severity
Here is the sorting rule we use on enterprise audits. Give every finding a queue label before you give it a priority.
Infra queue. Robots rules, WAF and bot-management policy, CDN behaviour by region, time to first byte, server-rendered HTML for content that currently arrives empty. Owner is platform engineering or security. These need a change ticket and a deploy window, not a review board. On our enterprise audits they are also where the recoverable findings have tended to concentrate, though we have not scored that across a sample we could publish.
Markup queue. Organization schema, sameAs links, parentOrganization and subOrganization so the group and its divisions resolve as one entity, canonical tags, sitemaps. Owner is web engineering. Schema.org documents legalName, sameAs, parentOrganization and subOrganization on the Organization type, and none of them is a marketing claim, which is why in our experience they rarely reach legal review.
Copy queue. Answer-first openings, definition paragraphs, FAQ blocks that say something. Owner is content. Usually brand review, sometimes legal.
Claims queue. Pricing, comparison language, anything with a number about performance, anything regulated. Owner is legal and compliance. Expect weeks. In regulated categories, expect longer, which is the whole subject of AEO for fintech.
Run the first two queues immediately and the last two in parallel on their own clock. The reason this works is mechanical rather than political: access and identity problems block every downstream improvement. A page legal has blessed is worth nothing if the fetcher never renders it.
The entity split that large groups create for themselves
Here is the failure mode that is specific to size, and it is not a content problem.
A group with several divisions typically publishes under one trading name, several legal entities, a handful of regional domains and a couple of acquired brands that kept their own sites. Each property has its own Organization block, written by a different agency in a different year. The legalName on the German site does not match the one on the global site. Two properties claim the same Wikidata identifier in sameAs. One division's site has no parentOrganization at all.
An engine assembling an answer about your company has to resolve whether these are one entity or four. How that resolution works is not documented by the engines we checked, and we cannot see inside it. What we can see is the output: when we ask about groups whose own markup conflicts, the answers we get back are more often vague or split across two mentions than wrong. That reads to a reader as absence rather than as being outranked.
Run this check, it takes an afternoon. Pull the JSON-LD from your top twenty properties. Build a two-column list of every legalName, name, url and sameAs value. Then ask four engines "who owns [division brand]" and compare their answers to your own list. In the checks we have run this way, the places where the engines disagreed with each other lined up often enough with the places where the markup disagreed with itself to be worth looking at first. It is a pointer, not a proof of cause. The fix sits in the markup queue, so it ships in weeks rather than quarters, which is the main argument for doing it early.
The silent regression in the security queue
A rule that nobody in marketing will see: security teams change bot policy on their own cadence, and bot policy is an AEO control.
Two engines document this, and only two, so take the rest on trust at your own risk. OpenAI's crawler documentation (read 12 October 2026) says that for search results it can take about 24 hours from a robots.txt update for their systems to adjust, and that a site opted out of OAI-SearchBot drops out of the answers ChatGPT's search feature writes while remaining eligible to show as a plain navigational link. Google's crawler documentation (read the same day) separates Google-Extended, Google-CloudVertexBot and GoogleOther, each controlling something different, and states that Google-Extended does not affect inclusion in Google Search or ranking in it. That is four distinct levers across two engines. In a large organisation they are usually pulled by someone who has never heard the phrase answer engine optimisation, during an incident, at speed. What the other engines do with a robots change, and how fast, we cannot tell you, because they do not say.
The practical defence is boring. Put robots.txt and the bot-management policy under version control, diff them on every deploy, and alert a named person on change. Add the same check to your AI crawler log review. If you have no owner for that alert, read who owns AEO inside a company before you write another content brief, because an unowned alert is the same as no alert.
Do not let scale justify a six-month pre-programme
Enterprise plans have a habit of growing a long foundational phase before anything ships. A taxonomy project. A schema programme across every division. A new file format somebody read about.
Google's own guidance on AI features is blunt about the last of those, for Google: a page must be indexed and eligible to be shown in Google Search with a snippet, and the page states there are no additional technical requirements and no special optimisations necessary to appear in AI Overviews or AI Mode. That covers Google and nothing else. It is still worth quoting in a steering committee, because for the largest answer surface it converts a proposed six-month programme back into a two-week ticket.
Spend the saved time on measurement instead. One dated measurement is enough to justify the attention: Pew Research Center, analysing 68,879 Google searches from the browsing data of 900 US adults in March 2025, found users clicked a traditional result link in 8% of visits where an AI summary appeared, against 15% of visits where none did, with 18% of the searches in the study producing a summary at all. That is one engine, one country, one month and one opt-in panel, not a reading of the web. It is still the reason to measure mentions and clicks separately, because a click count alone would not have shown it.
What we run for clients at this size is the same audit as everyone else gets: about 45 prompts across five engines, with retrieval on and off, evidence attached to each finding, and the report as the deliverable. The sample audit report shows the shape. The only thing we change for a large organisation is the queue label on every finding, so the report can be split across four owners on day one instead of sitting with one person who cannot action most of it. Where the emphasis shifts by sector is covered in AEO by industry: where the work differs.
Honest limits
This post establishes a way of sequencing work. It does not establish that the sequencing causes faster answers, because we have never run the controlled comparison that would show it: the same organisation, the same findings, one order against the other. What we have is the engagements we have run, with no register of durations we could publish, so the queue claim is experience and not evidence.
The crawler behaviour here is documented by OpenAI and Google only. We have no equivalent documentation for the other engines named on this blog, and absence of a published rule is not a rule. The Pew figures describe Google summaries seen by an opt-in US panel in one month of 2025 and should not be read as the click behaviour of your own audience.
The entity check tells you where engine answers and your own markup both disagree. It does not prove the markup caused the answer, and the engines do not expose the resolution step for inspection. Treat the whole method as a working one.
FAQ
Who should own AEO in a large company? One accountable owner in marketing or digital, with standing access to platform engineering and a named contact in security. The owner does not need to do the work. They need to be able to open tickets in four queues without negotiating for each one.
Does an enterprise need different AEO than a small company? The mechanics are the same ones. The constraints are not. Scale adds entity fragmentation across divisions, slower approvals, and a security function that can change bot policy, and with it your eligibility for the answers the engines that document this write, without telling anyone.
Should we block AI crawlers while legal reviews the policy? Understand the cost first. OpenAI documents that opting out of its search crawler drops you from the answers its search feature writes while leaving you eligible as a plain navigational link, and Google documents that its training and grounding token does not affect Search. Those are different levers, documented separately, so decide them separately, and check each engine's own documentation rather than assuming the pattern carries.
How do we prove this to a steering committee? Pick ten prompts a real buyer asks. Run them before the change, record whether you were named and whether the claim was correct, make one scoped fix, wait, run them again. A before and after on ten prompts argues better than a dashboard score nobody can audit.
Sources
- Pew Research Center, Google users are less likely to click on links when an AI summary appears in the results, 22 July 2025: www.pewresearch.org/short-reads/2025/07/22/google-users-are-less-likely-to-click-on-links-when-an-ai-summary-appears-in-the-results/
- OpenAI, bots and crawler user agents: developers.openai.com/api/docs/bots
- Google Search Central, Google crawlers and user agents: developers.google.com/crawling/docs/crawlers-fetchers/google-common-crawlers
- Google Search Central, AI features and your website: developers.google.com/search/docs/appearance/ai-features
- Schema.org, Organization type definition: schema.org/Organization