What access does an AEO agency need to your website?

An AEO agency needs enough access to read your pages as a machine sees them, to change the ones you have agreed are in scope, and to see what search already sends you. That is a smaller list than a typical onboarding form asks for, and the gap between the two is where most of the security argument in a procurement review happens.

Reading the page as a machine sees it is the part buyers tend to skip, and it is the first thing worth granting, because the alternative is a programme built on what the page looks like in a browser. Shuyang Zhang of The Hong Kong Polytechnic University fetched 10,307 URLs with a static client and a rendered browser client and found that 20.9% of the HTTP 200 responses the static client received contained no main content, with 13.1% of sites returning 200 for paths that do not exist (arXiv 2611.00884, submitted 31 October 2026). A page that answers 200 and carries nothing is invisible to anything that does not run your JavaScript, and nobody finds that from a logged-in CMS preview.

The change rights come next, and they are narrower than they sound. Most of what this work touches is page copy, headings, metadata and structured data, all of which an editor role covers in WordPress, Shopify or Webflow. Our own methodology page states which platforms we implement on, and the work itself is ordinary content editing rather than development.

Then there is the small set of changes that live outside the CMS entirely: robots.txt, the robots meta tag, redirects and sometimes a rendering setting. Those need a route rather than a login. A named developer who takes a ticket is a perfectly good route, and it is the one most security teams prefer.

Does an AEO agency need full admin access to your CMS?

Full admin access is almost never necessary, and granting it is the most common over-grant in this category. An editor role with publishing rights on the pages in scope covers copy, headings, metadata, internal links and, on most platforms, structured data.

Admin gets requested for four real reasons, and each has a narrower answer. Installing a plugin, which a named developer can do once rather than a vendor doing at will. Editing a template, which is a scoped development request. Managing redirects, which usually has its own role or plugin permission. And reading a setting the agency cannot otherwise see, which a screenshot answers.

Three rules keep this clean without slowing the work down. Create a separate named account for the vendor rather than sharing an existing login, so the page history attributes every change to someone. Confirm the role can publish rather than only save drafts, if you have agreed that the agency ships changes, because a vendor with draft-only rights and a deadline becomes a queue in somebody's inbox. And put a review date on the account.

If your approvals process requires that a human signs off every change, say so in the contract rather than solving it with permissions. The question to ask a vendor, from Mike King of iPullRank, is "The review your team must do before any automated fix goes live" (4 November 2026, from a firm selling agency services in this category). Any vendor proposing automated page rewrites should be able to describe that review before you grant anything. How compliance-heavy teams structure that approval is covered in our guide on doing AEO when legal and compliance approve every page.

What has to change outside the CMS, and who should do it?

Four things usually sit outside the CMS and matter more than their size suggests: robots.txt, the robots meta tag, redirects, and how the page is rendered. Each is a retrieval-stage control, which means a mistake there cancels every improvement made anywhere else.

The robots meta tag is the one worth auditing before an engagement starts, because it now reaches AI surfaces and it fails without any visible symptom. Google's robots meta tag documentation states that nosnippet applies to "all forms of search results (at Google: web search, Google Images, Discover, AI Overviews, AI Mode)" and "will also prevent the content from being used as a direct input for AI Overviews and AI Mode", while max-snippet "will also limit how much of the content may be used as a direct input for AI Overviews and AI Mode" (read 12 November 2026). A nosnippet set years ago as an ordinary snippet decision is now an AI opt-out nobody chose.

Crawl access is governed separately. Google's guidance on AI features states that "robots.txt directives for Googlebot is the control for site owners to manage access to how their sites are crawled for Search", and points site owners to Google-Extended to limit "AI training and grounding in some of Google's other systems" (read 12 November 2026). Those are different levers with different effects, and conflating them is how a site ends up out of AI Overviews while believing it only opted out of model training. Our guide on whether to block AI crawlers like GPTBot covers the equivalent decisions for the other engines.

Give the agency read access to these files and a ticket route to change them. A vendor who wants write access to robots.txt on day one is asking for the most dangerous permission on the list to save a day of latency.

What analytics and Search Console access should you give?

Read-only access to Search Console and your analytics is enough, and it is worth granting on the first day because it is the only record of what search already sends you. Neither needs an editing or admin role for this work.

Search Console carries the query and page data that shows which questions already reach you and where you sit on them, plus Google's generative AI report, which has one notable limit: it reports impressions in AI Overviews and AI Mode and no clicks, no position and no query dimension. What that report can and cannot answer is covered in our guide on seeing AI Overviews traffic in Search Console.

Analytics matters for a narrower reason: assistant referrals arrive inconsistently, and some of them land as direct traffic. An agency reading your analytics should be able to tell you which of your sessions genuinely came from an assistant and which are a reporting artefact, rather than presenting a direct-traffic rise as a win. Our guide on whether your direct traffic spike is hidden AI traffic sets out how to test that.

Two access notes save trouble later. In Search Console, grant a restricted user rather than an owner, because an owner can add other owners and change property-level settings. In analytics, grant viewer or analyst rather than editor, since an agency does not need to change your data collection to read it. Both tools also log who looked at what, which is the sort of thing a security review asks about and almost nobody checks afterwards.

Which access requests should you refuse?

Refuse anything that touches your domain, your mailbox, your customer data or your billing, because none of it is needed to improve how your pages are retrieved and quoted. These requests usually come from an onboarding template built for a wider marketing engagement rather than from the work itself.

Request	Why it gets asked for	What to grant instead
CMS administrator	Plugins, templates, redirects	Editor with publish rights on pages in scope, plus a developer ticket route
Domain registrar login	Rarely justified at all	Nothing. Make registrar changes yourself
DNS access	A verification record	Add the single TXT record yourself and confirm it
Search Console owner	Convenience	Restricted user, which can read every report
Analytics editor	Setting up events or goals	Viewer, and a scoped request for any tracking change
Server, FTP or hosting panel	robots.txt, headers, rendering	Read access, with changes through your developer
CRM or customer data export	Attribution and lead quality	An aggregate report you produce, or nothing
A shared login used by several people	Habit	One named account per person, always

One request deserves its own conversation rather than a yes or no: a plugin or script that edits pages automatically on the vendor's instruction. That is a standing write permission to your live site held by software, and whether it is acceptable depends entirely on the review that sits in front of it.

Where the honest answer is that nobody internally has time to review changes, say that out loud during selection. It changes which model fits, and our comparison of an agency against a tool against doing it in-house is built around exactly that constraint.

What will a security review ask the agency for?

A security review in B2B usually asks the same six things, and a vendor that has answered them before will have the answers ready rather than assembled over a week. Knowing the list in advance is what keeps an AEO engagement from stalling in procurement for a month.

Expect questions on where data is stored and for how long, which subprocessors touch it, whether accounts use two-factor authentication or single sign-on, what happens to your data when the contract ends, who at the vendor can access your systems, and whether a data processing agreement is on offer. None of that is specific to AI visibility work. What is specific is a seventh question worth adding yourself: what exactly gets sent to third-party AI engines during the work, since sampling buying questions means putting prompts into systems you do not control.

That last one has a simple honest answer in most engagements, which is that the prompts are buying questions a prospect would type and contain nothing confidential. If a vendor cannot describe what leaves your environment, that is worth resolving before access is granted rather than after.

A couple of habits make the review go faster. Ask for the vendor's security documentation during selection rather than after signing, because a boutique firm may not hold the certifications a large enterprise process expects, and that is better discovered early. And if your process requires a formal review of every subprocessor, flag the AI engines themselves, since they are part of how the measurement is produced. Our guide on getting budget approved for AI search visibility covers the rest of the internal path, including procurement.

How do you hand over access and take it back at the end?

Hand access over as named, time-limited accounts, and write the revocation into the contract rather than trusting it to an exit conversation. The handover question most buyers get wrong is not what to grant, it is what they keep when the engagement stops.

At the start, create one account per person who needs it, record who requested each one, set a review date, and ask the vendor to tell you when staff on your account change. Keep a change log of what was edited and when, by page, so that a movement in citations three months later can be lined up against something real. Where a vendor edits pages, that log is also the only way to roll a change back cleanly.

At the end, revoke the accounts the same week, rotate any credential that was shared, and remove the vendor from Search Console and analytics. Then collect what belongs to you: the prompt set, the measurement history, the page changes themselves, and any documentation of what was tried and did not work. King's fourth vendor question is the right thing to ask before you sign rather than after: "What you can export, how much history you keep, and what happens when the subscription ends" (iPullRank, 4 November 2026).

Access decisions are also a reasonable proxy for how a vendor works. A firm that asks for the least it needs, explains why each item is on the list, and can name what you keep at the end tends to be a firm that documents its work. If you want to see what a vendor does with access before granting any, a free visibility assessment is run entirely from outside your systems: it samples your buying questions across ChatGPT, Perplexity, Google AI Overviews and Claude and reads your public pages the way a crawler does. Our own teardown of one of our own pages shows what that reading produces, including the score of 28 out of 100 it gave us and the 71 we reached after the fixes.

What else do people ask about giving an AEO agency access?

Procurement and marketing teams ask these five questions most often while granting access for AI visibility work.