AI Search Optimization for Site Migrations: Checks Before and After Launch

AI search preparation for a site migration starts with two checks: old URLs must lead to the right information, and new URLs must remain eligible for Google Search.

A domain or URL change involves redirects, content, search settings, and a record of the site before the move.

Google's AI Overviews and AI Mode are search features that display links to relevant web pages alongside AI-generated answers.[1]

This guide explains how web teams and their development partners can build a migration checklist for those two features.

The factual guidance comes from Google's official documentation checked on October 13, 2026; the worksheets and division of responsibilities are editorial recommendations.

This is a planning guide, not a case study based on a completed migration or testing in a live Search Console account.

Define the scope of AI search preparation for the move

Start by preserving Google's ability to read pages and consider them for links in Search and AI responses.

AI search optimization, also called AIO, covers work intended to help information appear in AI-powered search.

Google says that AI Overviews and AI Mode require no special optimization beyond the practices used for conventional Search.[1]

List what will change: the domain, page URLs, content, or hosting infrastructure.

Even when URLs stay the same, missing content or unintended search restrictions still need attention.

For a broader review of a site that is not moving, see the AIO checklist.

For this migration, track each affected URL together with the settings that will change.

Understand eligibility for Google's AI search features

A page must be indexed and eligible to appear in Google Search with a snippet to be considered as a supporting link in Google's AI features.[1]

Indexing means that Google has added information about a page to its search index.

A snippet is the short description that accompanies a page title in search results.

Opening the destination page does not establish either condition.

Check access to the new URL, the availability of essential content, and any unintended indexing or display restrictions.

For a service page, for example, check that eligibility and terms remain available alongside the service name.

This is an illustrative example, not a claim about a particular company's results.

After launch, use Search Console, Google's site management tool, to inspect the new URL's indexed information.

Track AI search appearances separately.

Google does not guarantee crawling, indexing, or visibility even when requirements are met.[1]

A passed settings check therefore cannot promise that links in AI responses will be preserved.

Distinguish URL changes from redesigns that keep URLs

A move that changes URLs requires an old-to-new mapping and redirects; a move that preserves URLs focuses on the new hosting environment and the content it serves.[2][10]

The word “redesign” alone does not establish which work is needed.

Compare the actual addresses people will open.

Change	Effect on URLs	Main checks
Domain	The site's address changes	URL mapping, redirects, ownership
Page paths	Addresses can change within one domain	Page mappings and internal links
Hosting	URLs may remain unchanged	Connectivity, content, images
Design	Depends on the implementation	Whether URLs change and content renders

A redesign that changes article paths is also a URL migration.

A hosting-only move does not need redirects for URL changes that do not exist.

When URLs remain unchanged, test pages and downloads on the new hosting environment, then monitor requests to the old and new servers after switching.[10]

Add a “URL changes: yes/no” field to the mapping so that editors and developers work from the same scope.

Separate domain, CMS, and design changes

Where possible, carry out the domain move, CMS replacement, and redesign one at a time.

A CMS is the system used to manage articles, products, and other website content.

Google recommends making changes sequentially instead of combining several major changes at once.[2]

One option is to move the domain first and change the design later.

Rewriting content at the same time can make it harder to distinguish URL migration problems from content changes.

For large sites, Google also describes moving a smaller section first where technically feasible.[2]

A relatively stable section that is less affected by unpredictable events can be a candidate.

A successful partial move does not prove that the entire migration will be problem-free.

Record the change scope, implementer, reviewer, switchover time, and person responsible for a recovery decision.

These worksheet fields are our operational recommendation.

Keep separate work records even when changes must happen on the same day.

Agree in advance which person should investigate each setting if a problem appears.

Save old URLs and an AI search baseline before migrating

Before the move, save the old URL inventory and the search and AI visibility data available at that time.

Waiting until after launch can leave too little evidence for comparing the former content and settings.

Build the inventory first and preserve the original exports unchanged.

Add new URLs, content requirements, and test results to a working copy.

Treat search impressions and actual website visits as different measures.

Google's generative AI report provides information about link impressions in its AI search features.[11][12]

If a report cannot be obtained, record the reason and date instead of replacing missing values with zero.

Choose a shared storage location and file names that identify the property, reporting period, and export date.

Preserving a baseline does not, by itself, prove that the migration later caused a particular result.

Collect old URLs from the CMS, sitemaps, and logs

Build the old URL inventory by combining CMS exports, sitemaps, access records, and link information.[2]

A sitemap tells search engines where pages can be found.[7]

A URL that no longer appears in the current CMS list may still receive visits through external links.

Use the following sequence to make coverage easier to check.

1. Export the URLs of published pages from the CMS.
2. Compare them with URLs in the current sitemap.
3. Add URLs used in server access logs or analytics records.
4. Review pages with internal and external links in Search Console.
5. Include references to images, videos, PDFs, and other assets.

Export methods vary by CMS and hosting environment, so ask the responsible team for the relevant lists.

Specify the date range and whether unpublished pages are included.

Choose a log period that accounts for the site's seasonal traffic patterns.[2]

Do not retire a page solely because it received no visits during a short observation window.

Keep the source of each inventory entry so that the scope of the review remains traceable.

Save the generative AI report and manual observations

Keep Search Console's generative AI report separate from records of questions tested manually before the move.

Google says the report shows impressions for AI Overviews and AI Mode.[11][12]

Use the report link in the official help page to open a property for which access is available.

Choose the reporting period and review the page, country, and device dimensions needed for comparison.

Export chart and table data, and record the selected conditions separately.[12]

The download converts values displayed as “~” or “-” to zero, so preserve the fact that those values were unavailable.[12]

For manual checks, record the exact question, AI feature, date and time, displayed link, and URL actually opened.

A question about the service being migrated can be reused after launch.

Treat each answer as an observation at that moment.

Neither report impressions nor manually observed links represent visits or conversions.

If the report is absent, check possible explanations such as insufficient impressions in the official help and record “report unavailable.”[12]

Map old URLs to new URLs and retained content

The URL mapping should capture both redirect destinations and the explanations that must remain on the new pages.

Google's migration guide includes preparing an old-to-new URL mapping.[2]

The following fields are a proposed worksheet for coordinating that work.

Field	What to record
Old and new URLs	Complete addresses
Page treatment	Retain, merge, or retire
Content to retain	Reader question, audience, conditions, evidence
Planned settings	Redirect method and launch-time restriction changes
Observed results	Response, final URL, content review
Owner and review date	Implementer, reviewer, date and time
Open issues	Unresolved details and next responsible person

When merging service descriptions, record where the old page's conditions can be read on the new page.

This is an example of how to fill out the worksheet, not a completed migration record.

Use “undecided” for an unknown destination and “untested” for an unmeasured response.

A planned value of 301 does not establish that the server actually returns it.

Each row should make both the intended behavior and the observed result easy to find.

Review the content and references moving to new URLs

The new page should answer the old page's question and preserve the conditions and evidence needed to understand that answer.

A page with the same title is not a complete replacement if essential explanations are missing.

Google recommends making important information available as text and providing helpful content for its AI features.[1]

Compare old and new pages side by side for audience, service scope, conditions, and supporting materials.

This does not mean that identical wording or an unchanged heading count is a requirement for keeping AI citations.

Update outdated explanations against current evidence.

Record retained content, updates, and reasons for retirement in the mapping.

Complete the content review only after checking both the page's destination and the accuracy of its explanation.

Preserve the question, conditions, and supporting evidence

Compare the information readers need to make a decision, item by item.

For a service page, that may include who can use it, what can be requested, and which conditions affect pricing.

This example does not assume any particular price or business outcome.

Review notes, tables, and reference links as well as headings.

If a table was removed during a redesign, check that exclusions were not removed with it.

Any retained figures need matching sources and reporting periods on the new page.

A displayed update date should reflect the material actually reviewed.

Following Google's guidance on text availability, keep essential explanations in the body even when they also appear in diagrams.[1]

Give the implementation team a list of reviewed items and differences, rather than a generic “content migrated” status.

If content updates and display checks have different owners, record which task remains incomplete.

Return to the source material wherever the new explanation leaves conditions unclear.

Moving a page should not turn outdated information into a newly published claim of accuracy.

Choose destinations differently for merged and retired pages

Use a new page as the destination when it contains the relevant replacement content; otherwise, consider an appropriate removal response.[2]

A redirect sends a request for an old URL to another URL.

When several pages are merged, first read the destination to confirm that it addresses the original questions.

For example, a combined service page should still distinguish the audiences and conditions of the services it replaces.

Avoid sending unrelated old URLs to the home page.

Google's migration guide advises against redirecting many unrelated URLs to a single destination.[2]

For retired pages without replacement content, discuss responses such as 404, meaning not found, or 410, meaning gone, with the implementation team.[2][9]

Check the server's actual response as well as the wording of the error page.

Record either the content relationship to the merged destination or the reason for retirement.

For a problem that already involves broken links, see the AI referral broken-page checklist.

Include images, PDFs, and download destinations

Include images and PDFs linked from the body in both the old URL inventory and the destination review.

Google's migration guide includes moving images and downloadable materials in the preparation work.[2]

The article may move while its download links still point to the old server.

Before retiring the old environment, open page images, document links, and downloaded files.

Check both whether the file can be retrieved and whether it contains the intended version.

An unchanged file name does not prove that the content or language is correct.

For materials hosted by an external service, confirm the link and access settings with the owner.

A migration does not require making a restricted document public.

Distinguish material intended for public access from information that should remain restricted.

Provide important explanations, such as pricing conditions, in text as well.[1]

Check alternative text and body explanations instead of assuming that the presence of an image completes the transfer.

Finally, follow the links from the new page and record the asset owner and review date.

Check crawling and URL signals before launch

Before launch, check that the new pages can be read, unintended search restrictions are removed, and canonical signals point to the intended URLs.

Crawling is the process by which systems such as Google access pages to retrieve information.

Development sites may use authentication or search restrictions to protect material before release.

List the settings to remove at launch and those that should remain.[2]

Apply changes to the pages intended for public release instead of removing every restriction indiscriminately.

Templates and hosting settings can affect many pages at once.

Select examples of the page types actually used, such as articles, products, and service descriptions, rather than testing only the home page.

Plan to repeat the checks on the production URLs after the switchover.

Review authentication, robots.txt, and noindex

Check authentication, hosting-level access blocks, robots.txt, and noindex separately.

The robots.txt file tells crawlers which parts of a site they may access.

The noindex rule tells a supporting search engine not to index a page.[8]

Google must be able to crawl the page to discover its noindex rule.[8]

Blocking crawling in robots.txt is therefore not a substitute for making Google read noindex.

Use a record such as the following to distinguish the settings.

Setting	What to confirm
Development authentication	Whether public pages open without an unnecessary login
Hosting and protection settings	Whether Google's access is unintentionally blocked
robots.txt	Whether intended public URLs are blocked
Page HTML	Whether an unintended noindex remains
HTTP response headers	Whether X-Robots-Tag contains an unintended noindex

HTML describes the page, while HTTP response headers carry information returned by the server alongside the body.

Google's migration guide calls for reviewing development restrictions before the move.[2]

Ask the settings owner to identify where each rule is applied, including headers and templates where relevant.

Do not remove access protection from information that is meant to remain private.

Recheck the actual production URLs after launch, since preparation-environment results alone do not establish the public behavior.

Review text availability and snippet restrictions

Keep important information available as text, and check that snippet restrictions match the intended publication policy.[1]

Google recommends text availability for important content and structured data that matches what is visible on the page.[1]

Structured data describes information such as products or articles in a form search engines can interpret.

If a redesign puts an explanation into an image, retain essential terms and decision-making information in the body.

Search Console's URL Inspection tool can show fetched HTML and the rendered page from a live test.[5]

Compare the visible content with the retrieved material.

Snippet controls include nosnippet, data-nosnippet, and max-snippet.[1]

Ask the implementation team whether the new template introduces or changes any of these controls.

Do not remove deliberate restrictions solely to pursue greater visibility.

Google does not require a special AI text file or special structured data for its AI search features.[1]

Check the existing content and display policy before treating extra files as a migration requirement.

Align canonicals, internal links, and sitemaps with new URLs

Align canonicals, internal links, and sitemaps with the new URLs intended for publication.[2][4]

A canonical indicates the preferred representative URL among pages with duplicate or similar content.

Check self-referencing canonicals on new URLs as well.

A page may open on the new domain while its template still declares the old domain as canonical.

Compare the following items with the URL mapping.

1. Does the canonical point to the intended new URL?
2. Do body and navigation links use the new URLs?
3. Does the sitemap list the new URLs intended for search?
4. If hreflang is used, have language and region alternatives been updated?

Hreflang identifies alternative pages for different languages or regions.[2]

A declared canonical expresses a preference, so check Google's selected canonical separately.[4][5]

Do not use noindex as a substitute for choosing a canonical URL.[4]

For more on duplicates, see the guide to canonical URLs for duplicate product pages (Japanese).

Test redirects for the URL migration

Test whether each old URL behaves as mapped, using both the actual HTTP responses and the destination's content.

A redirect sends requests for an old URL to a different address.

Saving the configuration does not prove that it works in production.

Google recommends preparing the URL mapping, implementing redirects, and testing them.[2]

Record the old URL's response, intermediate URLs, and final destination together.

Even if the final page opens, the content review remains incomplete when required explanations or documents are missing.

Opening a new URL directly does not test the journey from an old link.

We recommend having the implementation team review the redirect path and the editorial team review the content, with both results in the same mapping.

Use 301 or 308 redirects directly to permanent destinations

For a permanent URL move, use server-side permanent redirects with a 301 or 308 response to the corresponding destination.[2][3]

These HTTP status codes indicate that a page has moved permanently.

An HTTP status code describes the server's response to a request.

Google treats permanent redirects as a strong signal that the destination should be canonical.[3]

That does not mean every displayed search URL changes as soon as the redirect is configured.

When an old article moves to a new article, check that the redirect points directly to that replacement.

Update rules that still send traffic through an earlier destination before reaching the new site.

Google recommends avoiding redirect chains and pointing directly to the final destination where possible.[2]

Temporary moves use a different treatment, including 302 or 307 responses, so match the response to the purpose of the move.[3]

Implementation differs by server and CMS; verify the returned response rather than relying on a setting's label.

List wrong destinations, chains, and loops

Record wrong destinations, multi-step chains, and loops as distinct findings.

Google's migration guide calls for redirect testing, and its HTTP documentation describes errors involving excessive chains or loops.[2][9]

A working representative page does not establish that every URL is configured correctly.

Test the old URLs in the mapping with appropriate HTTP inspection tools or server checks.

The following table is a proposed format for recording results.

Check	Record	Condition to investigate
Initial response	Actual status code	A response inconsistent with the intended permanent move
Redirect path	Intermediate URLs	Unnecessary hops or a return to a previous URL
Final URL	Address actually reached	A destination that differs from the mapping
Final response	Destination response	An error or unavailable page

Treat blank cells as untested, and do not put planned values in the observed-results column.

After a correction, retest from the same old URL and update the result and timestamp.

Include migrated images and PDFs as well as ordinary pages.[2]

Check the redirect path and destination content separately

Once the redirect path passes, open the final page in a browser and review its content and document links.

A 200 response indicates successful retrieval, but does not guarantee indexing or establish that the page contains the required information.[9]

For example, an old pricing URL may reach a new page that is still missing the applicable conditions.

This is an illustrative scenario, not an observed migration result.

Compare the new page with the question, audience, conditions, and evidence recorded in the mapping.

Inspect the new URL directly in Search Console to review retrieval and indexed information.[5]

Do not treat URL Inspection alone as proof that the entire route from the old URL has been tested.

Record the method used for each check: HTTP responses for the path, and visible and retrieved content for the explanation.

For links in AI answers that are already broken, see the AI referral broken-page checklist.

During migration preparation, separate existing repairs from tests of the new redirects so that open issues remain traceable.

Coordinate launch-day work and the publication decision

Make the new site usable, test the redirects, and then complete the Search Console procedures that apply to the move.

Starting ownership verification or destination selection on launch day can leave the team without enough evidence to proceed.

Turn the preparation checklist into a launch schedule that records the order of work and its results.

Google's migration guide moves through preparation, URL mapping, redirects, and monitoring.[2]

We recommend adding owners, review times, open issues, and a decision-maker to that sequence.

Keep an implementation-complete message separate from a result checked on an actual URL.

An inaccessible important page needs attention before waiting for search visibility to change.

Older indexed information immediately after launch, on the other hand, does not by itself establish a failed migration.

Verify ownership and connectivity for both sites

Verify ownership of the old and new sites in Search Console and preserve the settings needed to keep that verification valid.[2]

Ownership verification demonstrates control of the site to Google.

If verification uses a file or tag, check that the CMS replacement has not removed it.

Google also advises considering relevant variations such as HTTP, HTTPS, and www or non-www addresses.[2]

To use the Change of Address tool, the same Google account must be a verified owner of both properties.[6]

Confirm access in the actual account instead of relying on an assumption that permissions exist.

For connectivity, test old-URL redirects and HTTPS access to the new URLs.

Record who maintains the old domain and certificates.

This article explains the official procedure; it does not claim to have verified ownership or connectivity for a particular site.

For the actual migration, record property names, reviewers, and timestamps, and leave unchecked permissions open.

Sequence redirects, the new sitemap, and Change of Address

After preparing the new site and enabling redirects, check that old URLs reach their mapped destinations.[2]

Then use Change of Address for an eligible move and submit a sitemap containing the new URLs.[2][6]

A sitemap tells search engines where pages are located.

Submitting it does not guarantee that every listed URL will be crawled or indexed.[7]

Change of Address informs Google that a site's address has changed.

Use the following distinctions when deciding whether the tool applies.[6]

Type of move	Change of Address tool
Move to another domain	Use when the eligibility conditions are met
Subdomain move	Use when the eligibility conditions are met
HTTP to HTTPS	Do not use
www to non-www, or the reverse	Do not use
Path changes within the same domain	Do not use
Hosting changes with unchanged URLs	Do not use

Even for an eligible move, the tool does not replace redirect configuration.

Meet its prerequisites, then record the submission and result in the launch schedule.

Moves that do not use the tool still require destination or hosting checks.

Decide how unresolved issues affect launch or repairs

Base the launch decision on whether important pages are usable, as well as the planned schedule.

This decision record is an editorial recommendation, not a Google publication approval system.

If a key page on the path to an inquiry is unavailable, assess the impact and decide whether to repair it or delay launch.

Keep unresolved noindex restrictions, unknown destinations, and missing essential explanations on the issue list.

Google recommends preparing the new site and reviewing development restrictions before the move.[2]

Put the following details in one record.

1. Affected URLs and unavailable information.
2. The decision to delay or repair and retest.
3. The implementer and the person reviewing the result.
4. The next review time and the basis for the decision.

Investigate server errors by their responses and affected scope.[9]

Search rankings can fluctuate during a move, so ranking changes alone should not trigger an automatic return to the old site.[2]

If launch proceeds with remaining tasks, carry them into the follow-up checklist instead of deleting them.

Review technical status and AI visibility after the move

Keep separate records for the current page, Google's indexed information, the generative AI report, and manually observed AI answers.

Each describes a different aspect of the migration.

A corrected live page can still differ from information Google retrieved during its previous crawl.[5]

Impressions in the generative AI report also do not mean that a specific question will produce the same answer every time.[1][12]

Record the observed fact, timestamp, comparison conditions, and next action in the mapping.

If content or product organization changed alongside the move, record those changes separately.

This helps avoid attributing every impression change to the migration.

Use a shared record to track both technical repairs and continuing observations of search behavior.

Compare live URLs with Google's indexed information

Use a live test for the new URL's current state and the standard URL Inspection result for Google's indexed information.[5]

The standard result reflects the last version Google retrieved and may differ from the current page.

Keep these items in separate fields.

Item	What it establishes
Live test	Whether the current URL can be retrieved
Last crawl	When Google retrieved the page
Indexing status	The state reported in Google's indexed information
Google-selected canonical	Which URL Google treats as representative

A successful live test does not establish that a page is indexed or determine Google's selected canonical.[5]

After correcting a page, request indexing where appropriate.

The request does not guarantee indexing or a particular appearance date.[5]

A sitemap can help communicate many new URLs.[7]

Specify whether an inspection concerns the old or new URL to avoid mixing redirect-source information with destination status.

If information has not updated, keep the observed result and the next review date instead of marking the check complete by assumption.

Compare reports using mapped URLs and consistent conditions

Use the old-to-new URL mapping and consistent country, device, and date filters when comparing the generative AI report.[12]

Page impressions are assigned to the final URL after redirects, which is often the canonical URL.[12]

Looking only at the old URL can miss data assigned to the new one.

For merged pages, use the mapping to identify the relationship between several old pages and their single replacement.

Report dates use Pacific Time, so distinguish them from a switchover recorded in Japan Standard Time.[12]

Recent data may be preliminary; retain the time at which the comparison was made.[12]

Charts and tables can use different aggregation levels, such as property-level and page-level aggregation, so their totals should not be assumed to match.[12]

A property with insufficient impressions may not show the report at all; do not label that state as zero impressions.[12]

If no pre-migration value was saved, record “no baseline.”

The report's impressions do not measure visits or inquiries.[11][12]

Fix errors and missing content first, then keep monitoring

If AI search visibility declines, begin with the old URL's response and the new page's content.

An inaccessible page or a missing explanation gives the team a concrete repair target before interpreting impression trends.

We recommend checking the redirect destination, replacement content, search restrictions, and crawl information in that order.

After a correction, retest the same URL and preserve the before-and-after results.

Google's migration guide also recommends monitoring traffic and crawling on both sites.[2]

For manual AI checks, reuse the recorded question and note the feature, timestamp, and linked destination.

AI Overviews and AI Mode can use different techniques and produce different answers and links.[1]

Failure to find a link in one test is not evidence that it disappeared for every user.

Even comparable reports and manual records cannot isolate a cause when seasonality or other changes are also involved.

Separate observed facts from open questions before attributing a change to the migration.

Common questions about site migrations and AI search

Maintaining old URLs and monitoring search behavior continue after launch day.

Finishing the launch checklist does not justify immediately retiring the old domain or redirects.

Google advises retaining redirects with both migration processing and users of old links in mind.[2]

A visible old URL in an AI answer and a broken route to the information are also different findings.

The following questions cover old-domain retention, outdated links, and the scope of checks outside Google.

Record an owner and next review date for these decisions so that the work survives a team handover.

Describe what has actually been checked without extending the result to other services or future visibility.

How long should the old domain and redirects remain?

Google's site migration guide recommends keeping redirects for as long as possible, generally for at least one year.[2]

It also suggests considering a longer period, or indefinite retention, for users.[2]

Account for people who may follow links in old documents or external websites when deciding what infrastructure to retain.

The Change of Address documentation mentions a 180-day period, but that is not a universal deadline for removing redirects.[6]

The tool's migration procedure and the redirects used by visitors serve different purposes.

We recommend recording responsibility for the old domain, renewals, HTTPS connectivity, and redirect checks.

Before simplifying the hosting setup, confirm that old URLs will still guide users to the new destinations.

Low traffic alone does not establish that historical links are no longer needed.

When considering retirement, review the then-current official guidance and usage, including how remaining links will be handled.

The passage of one year is not a guarantee that removing redirects is safe for every site.

Does an old URL in an AI answer mean the move failed?

An old URL observed in an AI answer does not, by itself, establish that the migration failed.

First check whether the link reaches the appropriate new page.

Then review the destination's content, search restrictions, and Google's indexed information.[1][2]

A permanent redirect is a strong signal for the new canonical, but it does not guarantee an immediate change everywhere the URL appears.[3]

Record the question, AI feature, timestamp, displayed URL, and actual destination.

If the destination cannot be reached, investigate the redirect or page; if it can, retain the old displayed link as a separate observation.

This distinction also gives the implementation team a more specific issue to investigate.

A working link still does not prove that AI visibility matches the previous state.

Google does not guarantee inclusion in its AI features, so this guide gives no deadline for old links to disappear or visibility to recover.[1]

We recommend relating configuration changes to recorded evidence instead of repeatedly changing destinations without a clear reason.

Do Google checks also verify ChatGPT and other AI services?

Completing Google's migration checks does not verify ChatGPT or other AI services.

The primary-source guidance in this article covers Google's AI Overviews and AI Mode.[1]

A browser check can establish whether someone can follow an old link, but each service's discovery and linking conditions need separate research.

Leave other services marked as unchecked until they have actually been examined.

Google impressions cannot be reinterpreted as citations in another AI service.

Use the AIO checklist to revisit the scope of a broader review.

For each service, record the questions, timestamps, and links observed.

Base the next repair on verified facts without promising preserved citations across every AI system.

Begin with an old-to-new URL mapping that includes content, redirects, indexed information, and AI visibility, then assign owners and identify the remaining checks.