Should you wait until after your website redesign to start AEO?

Waiting until after the redesign is the wrong sequence, and the reason is that AEO is not one project. Three separate things decide whether an AI engine names your company, and only one of them lives inside the website build.

Whether engines can retrieve your pages is genuinely a property of the new site, and belongs in the build specification. Whether your pages answer buying questions in buyer vocabulary is content work that can start now and migrate across, because the words do not depend on the template. Whether the engines know your company at all is built off your site over quarters, and your developers have no effect on it either way.

Pausing the second and third because the first is in flight is where the cost sits. A six month rebuild during which nothing happens off-site means arriving at launch with a better site and the same unfamiliarity, and then waiting again for the slow input to move.

The sequence that works is ordinary project management. Put the retrieval and structure requirements into the redesign brief so you are not retrofitting them later. Do the off-site and measurement work during the build. Hold the page by page rewriting until you know the new information architecture, unless a page is both high value and unlikely to move, in which case rewrite it now and carry the copy over.

One thing genuinely does argue for waiting, and it is narrow: if the redesign will change your URLs and you have a small team, rewriting pages twice is a real waste. That is an argument for sequencing the content work, not for standing still.

What gets lost if you do the redesign first and the AEO work afterwards?

Doing the redesign first costs you the two inputs with the longest lead times, and neither of them is page quality. Chen and Koudas, across 158,099 AI answers carrying 468,037 citations, found that which pages the engine's own search retrieves explains about 32% of the variation in what gets cited, while page properties explain 2.8%. They also found that ChatGPT includes brands it already knows in the searches it runs and sometimes names brands with no supporting page at all.

Both of those are time dependent in a way a page rewrite is not. Being retrievable after a URL change depends on recrawling and reindexing, which runs on the engines' schedule. Being known depends on accumulated third party presence, which runs on nobody's schedule but is always slower than a sprint.

There is a second cost that shows up later and hurts more, which is that you lose the before reading. If you have no baseline from before the migration, you cannot tell afterwards whether a drop in citations came from the new site, from the move itself, or from the normal week to week variation in AI answers. Given how large that variation is, the absence of a baseline turns any post launch problem into an argument instead of a diagnosis.

The third cost is opportunistic. Content freshness correlates with citation: Seer Interactive studied 7,683 cited pages carrying 47,097 citations across ChatGPT, Gemini and Perplexity between March and June 2026 and found 75% had been updated within the last year. A site frozen for a six month rebuild is a site whose pages are all getting older at once.

How long does a website migration take to settle in search and in AI answers?

A migration settles in classic search in weeks and in AI answers unevenly after that, and the two have different mechanics worth separating.

For Google, the site move documentation, last updated 20 August 2026, states that "a small to medium-sized website can take a few weeks for most pages to move", that larger sites take longer, and that the speed depends on the number of URLs and your server speed. It tells you to keep the redirects "for as long as possible", generally at least a year, and from a user's point of view indefinitely. Since AI Overviews and AI Mode draw on the standard index, that recrawl timeline is also your AI Overviews timeline: Google's AI features documentation says a page needs only to be "indexed and eligible to be shown in Google Search with a snippet", with "no additional technical requirements".

ChatGPT runs on a different index with its own crawler. OpenAI's crawler documentation says it can take about 24 hours from a robots.txt update for its systems to adjust, that sites opted out of OAI-SearchBot "will not be shown in ChatGPT search answers", and that each crawler setting is independent of the others. A staging site that blocked everything and shipped with the block still in place is the classic version of this failure, and it fails silently: the pages are fine and the engine never sees them.

What nobody can give you is a settling time for the recommendation itself, because the brand familiarity channel has no publication schedule. Plan the technical recovery in weeks, the citation recovery in months, and do not read the first four weeks after launch as a verdict.

What should go into the redesign brief so you are not retrofitting later?

Put retrieval, rendering and structure into the brief, and leave the fashionable extras out of it. The useful list is shorter than most agencies will tell you.

Specify server rendered HTML for anything you want cited. A page whose main content only appears after client side JavaScript is a page some crawlers will read as empty, which our page on whether AI crawlers read JavaScript covers in detail. Specify that every content page keeps a crawlable URL with no required parameters, that the sitemap is generated from the real page set, and that the launch checklist includes removing the staging robots.txt block and checking it in production rather than assuming.

Specify a page template that can hold the shape an answer engine lifts from: one H1, a short answer block near the top, headings long enough to carry a full question instead of a two word label, and a body that can hold a table. Those are template constraints, which is why they belong in a build brief. Retrofitting a heading style across 200 pages later is a content project nobody budgets for.

What not to specify as a requirement is the markup people sell as the AI fix. Google states on its AI features page that "There's also no special schema.org structured data that you need to add" and that you do not need to create new machine readable files or AI text files to appear in these features. Schema and FAQ markup cost almost nothing to emit and are worth keeping as hygiene, and the measured case for them as a citation lever is weak, which we set out in does schema markup help you get cited by AI.

One line in the brief saves more than all of the above: a named owner who can publish a page change after launch without a release cycle.

What AEO work can you do during the build, before the new site ships?

Three workstreams run during a build without touching the new codebase, and they happen to be the three with the longest payback.

Start with the baseline. Run the buying questions in your category across the engines you care about, several times each, and record the cited sources as well as the answers. Do this before launch and you own the only comparison that will matter in month three. Make it more than one run per question: Schulte, Bleeker and Kaufmann, running four AI engines daily for 45 to 46 days in early 2026, found cited source sets overlapped between consecutive days by only 34% to 42% and recommend at least seven runs per prompt for a brand level reading. A single pre launch check is not a baseline.

Then the off-site work, which is the slow input and the one entirely independent of your build. Category roundups, directory and profile records, analyst and trade coverage, and the review sites your buyers read are all read by engines at answer time. Lily Ray, checking 100 business software queries in Google AI Overviews across three dates in 2026, found that brands which got recommended generally had more referring domains and more brand mentions than brands that were merely cited, and that where a brand's own best-of page was cited, the brand was left out of the recommendation in 224 of 323 cases.

Third, the question research. Deciding which questions your pages should answer, in the words buyers use, needs no CMS at all. Doing it during the build also makes the information architecture better, because you arrive at the sitemap discussion with a list of questions instead of a list of products. Our page on rewriting existing pages versus publishing new ones covers how that list turns into work once the template exists.

What if the redesign is a replatform or a domain change?

A replatform or a domain change raises the stakes and does not change the answer. The extra work is a complete URL mapping and a longer monitoring period, both of which Google's site move guidance sets out: prepare and test the new site, create a mapping from old URLs to new, start the move by setting up redirects, then monitor traffic on both the old and the new site.

Two differences matter for AI answers specifically. Redirect chains are tolerated by browsers and badly handled by some crawlers, so map old to new in one hop rather than through an intermediate pattern. And because ChatGPT, Google and Perplexity run separate indexes with separate refresh behaviour, a domain change will show up in their answers at different times. Seeing your new domain cited in one engine and your old domain in another for several weeks is expected and is not a sign the migration failed.

If the company name is changing as well as the domain, that is a harder problem than a migration, because the model's memory of your old name is not something a redirect reaches. We cover that separately in will a rebrand hurt your AI search visibility.

The table sets out what belongs where in the sequence.

Workstream	When	Why then
Baseline measurement	Before the build ships	It is the only comparison you will have afterwards, and it cannot be recreated later
Off-site presence and third-party records	During the build	Slowest input, independent of your codebase, and unaffected by the migration
Question and vocabulary research	During the build	Improves the new information architecture and survives any template change
Retrieval and template requirements	In the build brief	Template level choices are expensive to retrofit across a whole site
Page by page rewriting	After the URL structure is settled	Avoids writing the same page twice when the architecture moves
Post-launch verification	Launch week, then monthly	Catches the silent failures: a staging crawler block, a broken redirect, an unrendered template

If you want the baseline taken before your rebuild ships, our free visibility assessment records what the engines say about you now, which is the reading you cannot go back and collect later.

What else do people ask about AEO and website redesigns?

People ask these five questions about AEO and website redesigns once a rebuild is already scheduled and somebody has to decide what to do with the quarter in between.