A website relaunch can cost you rankings and organic traffic if important product or solution pages disappear or no longer answer buyers’ questions. SEO therefore needs to inform the new page structure: which entry points bring potential customers to the site today, and what must the new website preserve? Publicly accessible product information and a sound technical foundation also give you a basis for future visibility in search and AI Search.
What search visibility could you lose in a relaunch?
A product page can lose visibility even when its redirect works: the new destination no longer contains the information buyers were searching for. Before the migration, identify which existing pages answer specific buyer questions and where those answers will live on the new website.
Take a page about a CRM integration. It currently explains which data syncs and what prerequisites apply. During the relaunch, the page is folded into a general product page that no longer answers those questions. The redirect brings visitors to the new website, but it does not help buyers if the integration details are missing.
AI Search can also use publicly accessible product pages as sources. If an integration page disappears in the relaunch, its answers may disappear from AI-generated answers too. You cannot guarantee that Google AI Overviews or ChatGPT Search will cite a page.
If you also need to define the strategy, scope and process for the wider project, read path digital’s website relaunch guide.
How much SEO risk does your relaunch carry?
The SEO work you need depends on which content and URLs are changing. A visual redesign with stable URLs requires different checks from merging use-case pages or moving to a new domain.
| Change during the relaunch | Risk to search visibility | What to check |
|---|---|---|
Design or copy changes; URLs stay the same | Product value, target audience or integration details become unclear. | Compare how the old and new pages answer key buyer questions. |
CMS or hosting changes; URLs stay the same | Pages or product information become technically difficult to access. | Test status codes, visible text, indexability and internal links. |
Use-case pages or URL paths are merged | A page serving a specific search need loses its answer or destination. | Approve the content decision, URL mapping and direct redirect. |
Domain or language structure changes | New addresses and language versions are associated incorrectly. | Check that search engines can correctly connect the new domain and corresponding language versions. |
A page can lose relevance without a URL change if the new copy no longer answers specific buyer questions. A CMS migration with stable URLs does not need an old-to-new URL mapping. The new website still needs technical testing, as Google explains for this type of migration.
A relaunch can involve several changes at once. Before approving the design, establish who will evaluate existing pages and who will test the migration. Temporary ranking fluctuations are possible even with a sound implementation.
Which pages of your SaaS website should you keep or improve?
Prioritise pages by search intent and buyer journey: what question does each page answer for a potential customer, and how close are they to a product decision? A low-traffic page may matter more for a high-intent integration or comparison query than a widely read general guide.
Inventory your pages and buyer questions
Build an inventory of your existing pages and their search performance. Record the buyer question each page answers and whether it should be retained, revised or merged. For SaaS, this often includes product, use-case, integration and comparison pages.
For every important page, record what works today and what the new version must answer. A comparison page needs clear, defensible differences rather than interchangeable marketing claims. If public documentation or downloads receive search traffic, include those URLs in the inventory too.
Keep, revise, merge or retire pages
Keep a page if its question and purpose still exist. Revise it if your product or audience has changed. Merge it with another page only if the destination fully answers the original buyer question. If a permanently removed page has no suitable replacement, a blanket redirect to the homepage is not a helpful solution.
Document the decision for each important URL, along with the buyer question it currently answers and the planned destination. If you merge a page, make clear where its original answer will appear.
What needs to be ready for search before launch?
Before publishing, you need approval of the pages that matter to buyers and a plan for any changed URLs. Establish who owns the technical checks and who is responsible for unresolved risks. The decisive question is whether the new website still answers buyers’ questions.
When URLs change: choose relevant destinations
When you move or merge a page, its old URL needs a destination that matches the original content. For URL moves, Google recommends permanent, preferably direct redirects to relevant pages. A blanket redirect to the homepage is no substitute for a suitable destination.
Agree who will review the new destinations and redirects. If German and English paths change, the language versions must be correctly associated too. If URLs stay the same, you can omit the old-to-new mapping. You still need to approve the new content and confirm that the pages are accessible.
Keep product information accessible to people and search systems
Potential customers should be able to tell whom your product is for and which use case a page covers. Important details about integrations, requirements or limitations should appear in visible text, rather than only in an image or animation. This helps people compare options and gives search-based systems accessible information.
According to Google Search Central, the fundamentals of good SEO still apply to AI Overviews and AI Mode. During a relaunch, make sure product information remains available as readable text on the new pages. You do not need a special AI file or a separate “GEO schema” for that.
If ChatGPT Search matters to you, ask the implementation team to check whether OAI-SearchBot can access public pages. Allowing access removes a technical obstacle but does not guarantee a citation.
Which technical checks matter in a relaunch?
Do not test only the homepage: product, use-case and integration pages can use different templates and have different technical faults. Approve the new website only after checking the following points on the page types that matter to buyers.
| Element | What you should be able to verify |
|---|---|
Semantic HTML and links | Product answers appear as visible HTML text under real headings such as h1 and h2. Important pages are reachable through crawlable HTML links. This makes the content accessible to people and search systems. |
Fast mobile pages | Product information appears promptly on mobile devices, controls respond quickly and the page does not shift distractingly while loading. Check Core Web Vitals LCP, INP and CLS before launch, then monitor real-user data. |
XML sitemap and indexability | The XML sitemap contains the canonical live URLs you want indexed. Status codes, canonical tags and noindex rules on important product and integration pages must be consistent with it. A sitemap alone does not guarantee indexing. |
FAQs | Answer specific buyer questions visibly on the relevant pages. Google has not shown FAQ rich results since May 2026. Plan FAQs to help readers, not to win an extra search-result feature. |
Use only relevant, accurate structured data such as Organization, BreadcrumbList or BlogPosting. After a template change, check the markup with the Rich Results Test. |
What should you check after the relaunch?
Immediately after launch, check that important product and integration pages are accessible and that changed old URLs lead to the right destinations. Then review SEO performance and AI Search signals separately: a mention in an AI answer proves neither a visit nor a demo request.
On launch day: test pages and paths
If URLs changed, open the most important old addresses and check where they land on the live domain. Check the status of new pages, indexing signals and internal links. For multilingual sites, confirm that the corresponding language versions are correctly associated. An unexpected 404 or a leftover noindex rule is a concrete error to fix quickly.
The first day cannot tell you whether search performance has recovered. Search engines need time to process new pages and redirects, and AI answers do not use a fixed set of sources. A useful diagnosis compares the affected pages and topics with their state before the relaunch.
In the following weeks: compare visibility and demand
In Search Console, compare clicks, impressions and indexing for unchanged, moved and merged pages. If important product pages decline, check accessibility and redirects first. Then compare how the old and new pages answer the same buyer question. Account for reporting delays and seasonal demand.
Track AI Search separately from organic search. Google’s reporting for AI Overviews and AI Mode and Bing’s preview expose different signals; ChatGPT referrals may also appear in your web analytics. None of these figures proves qualified demand. If you see a notable change, first check whether the affected product pages are accessible and up to date after the relaunch.
For a B2B SaaS company, what matters is whether relevant buyers find the answer they need and take a useful next step. Connect page and referral data with demo requests or sign-ups where your tracking allows it.
What should the proposal say about SEO migration?
The proposal should say who will assess existing pages that receive search traffic and who will write the new website copy. Also establish who will approve product claims for accuracy.
If URLs change, the scope should include an approved mapping and redirect tests. You can omit that step when URLs stay stable. For acceptance, you need a list of open technical issues and who owns them. For the budget of the full project, see our guide to website relaunch costs.
