AI Chatbot During Website Relaunch: Staging, Redirects, and Go-Live QA

A website relaunch changes more than just design, navigation, and URLs. It also alters the knowledge base of an AI chatbot. New product pages replace old paths, help articles move to different sections, and some content disappears entirely. If the bot continues to operate on an outdated index during this transition, it will deliver fluent, but potentially incorrect or broken answers.

That is why an AI chatbot should not be treated as an afterthought or a downstream widget. It belongs in the relaunch plan alongside redirects, sitemaps, analytics, and forms. A controlled chain is essential: inventory sources, strictly isolate staging, index new content, test responses, and only then release the updated dataset to production.

Why the Chatbot Must Be Part of the Relaunch Plan

A classic relaunch test checks whether pages load, redirects work, and forms can be submitted. With a RAG-based chatbot, a second layer comes into play: Which text passages are retrieved, which source is cited, and does the response still fit the new site structure?

Retrieval-Augmented Generation, or RAG, connects a language model with custom content. The search component retrieves relevant text snippets from an index; the model uses them to formulate the response. Microsoft highlights key requirements such as relevant rather than exhaustive results, timely indexing, and controlled access to sources. For a relaunch, this means a correct redirect in the browser does not automatically update the chatbot index.

Therefore, plan three interconnected data flows. The web server redirects old URLs. Search engines receive canonicals, status codes, and an updated sitemap. The chatbot gets a newly built or deliberately updated knowledge base. Only when all three layers point to the same target pages is the migration consistent.

Preparing Staging Safely and Realistically

Protecting the Preview Without Skewing Tests

The staging website should not be indexed publicly by accident. For regular search engines, noindex or a corresponding X-Robots-Tag can serve as extra protection layers. However, Google points out that a noindex directive can only be read if the crawler is allowed to fetch the page. For truly confidential staging content, access control and authentication are therefore more critical than a simple robots rule.

The chatbot crawler still needs controlled access. Use separate credentials, a clearly defined allowlist, and a dedicated staging index. This prevents drafts from leaking into production responses while allowing you to test the bot with realistic site navigation, PDFs, and structured content.

Consistently Separating Configurations

Staging and production should never share the same index, webhook, or analytics data stream. Assign unique names and check before every test run which target each configuration points to. A basic sign-off checklist should include at least the domain, crawl starting points, allowed file types, exclusions, index name, and owner.

Forms and human handoffs are particularly critical. A test chat must not send real leads to sales or create live support tickets. Use marked test destinations and test the human handoff as a distinct workflow.

Combining URL Mapping and Source Inventory

Google recommends precise mapping of old to new addresses and permanent server-side redirects during site moves involving URL changes. For the chatbot, this same mapping list should be expanded with knowledge fields. This transforms a simple SEO spreadsheet into a shared management tool for web, content, and AI teams.

Track at least the following for each relevant source:

• Old and new URL, along with the expected HTTP status,
• Page type, language, and topic owner,
• Whether the source remains valid, is replaced, or is removed,
• Whether it is allowed in the chatbot index,
• Which test questions the source should cover.

Do not redirect old pages blanketly to the homepage. The new target page should match in content. For permanently moved content, permanent redirects are the correct signal; Google highlights server-side 301 and 308 redirects as permanent variants. Removed content without a genuine replacement should not artificially point to an irrelevant page.

Also verify internal links, canonicals, and the sitemap. The chatbot crawler should ingest the new target URLs directly, rather than constantly following redirects from old addresses. This reduces unnecessary requests and makes source citations in responses clearer.

Rebuilding the Knowledge Base in a Controlled Manner

A relaunch is a great opportunity to clean up your knowledge base. Remove duplicate drafts, outdated PDFs, and pages intended only for temporary campaigns or internal testing. Next, define allowed starting points and exclusions for the crawl. For a detailed guide, see our article Keeping Your AI Chatbot Knowledge Base Up to Date.

During indexing, headings, paragraphs, lists, and tables should be broken down into meaningful chunks. Overly large text blocks often deliver too much noise, while very small fragments lose context. Microsoft identifies chunking, vectorization, and hybrid search as building blocks of traditional RAG pipelines. However, the mechanism alone is not what counts—what matters is whether relevant new content is reliably retrieved for real user questions.

Run the initial full crawl on the staging index and log error pages, blocked files, and unusually small or large documents. Follow up with a second, incremental run. This verifies whether changes are detected correctly and whether deleted content is properly purged from the index.

Creating a Golden Set for Relaunch QA

A small spot-check with a few friendly questions is not enough. Build a golden set based on real search intents and expected key answers. For a structured approach to evaluating these tests, refer to our guide Measuring AI Chatbot Response Quality.

For the relaunch, the set should cover various risk categories:

• Questions about core products, services, pricing, and prerequisites,
• Questions whose answers have moved to a new URL,
• Questions regarding intentionally removed or merged content,
• Ambiguous formulations and typical typos,
• Questions in all languages actually supported on the site,
• Edge cases where the bot must not provide a definitive answer.

Do not evaluate wording alone. Check whether the correct source was retrieved, whether links point to the new domain and correct language path, and whether numbers, dates, and product names were accurately captured. A nicely phrased answer linking to an old URL is still a failed test.

Testing Routing, Forms, and Handoff Separately

Many chatbots do more than answer questions—they qualify leads or transfer conversations to human agents. Following a relaunch, new form fields, altered tracking events, or changed routing rules can break silently. Test at least one successful and one rejected flow for each primary destination. Also verify that consent text is visible and that submitted data arrives in the correct target system.

For multilingual websites, each language must be tested as its own user journey. A working English dialogue does not guarantee that French links, Croatian sources, or German handoff texts are accurate.

Executing Go-Live in a Controlled Sequence

The actual switchover should be brief and traceable. Freeze content changes for a strictly defined time window, export the final URL mapping, and document the approved index state. After that, the new website can be published and redirect logic activated.

A practical sequence looks like this:

1. Deploy production environment and verify basic page requests.
2. Check redirects, canonicals, sitemap, and robots signals.
3. Build the production chatbot index using approved sources.
4. Run the golden set against the production environment.
5. Test forms, analytics, and human handoff using tagged test cases.
6. Only then make the chatbot visible to all visitors.

If the chatbot must remain visible during the migration, consider running it in a restricted mode: answer only stable topics, transparently inform users of ongoing updates when unsure, and provide a direct contact option to a human team. Do not fabricate temporary answers.

Post-Relaunch: Targeted Monitoring of Error Patterns

During the first few days, your team should monitor more than just pageviews. Look closely at unanswered questions, fallback rates, source clicks, visits to old URLs, and conversations unexpectedly escalated to human agents. These signals reveal where mapping or knowledge base gaps remain.

Manually sample the most frequently requested responses. If the bot points to an old URL, the root cause could be in the stored document, the index, or a hardcoded response template. Fix the source, run a targeted re-index, and re-test that specific case. Regenerating all content blanketly makes troubleshooting much harder.

Also plan the decommissioning of staging access credentials and test webhooks. Deactivate credentials that are no longer needed, remove temporary allowlist entries, and explicitly archive or delete test indexes. This prevents temporary relaunch infrastructure from remaining an unmonitored security risk.

Quick Relaunch Checklist for Website Teams

• Chatbot owners are assigned in the relaunch plan and sign-off workflow.
• Staging is access-protected and isolated from the production index.
• Old and new URLs are mapped with source status and test questions.
• Crawl rules, languages, PDFs, and exclusions have been verified.
• The new index was tested via full crawl and subsequent incremental crawl.
• The golden set covers core questions, old URLs, negative cases, and handoffs.
• All links, numbers, names, and language paths in responses are accurate.
• Post-go-live monitoring procedures and responsibilities are defined.

Treating your AI chatbot as a dedicated relaunch workstream prevents outdated answers and broken sources. At the same time, it establishes a clean workflow that can be reused for future content updates. For technical integration tips, see our article on Integrating an AI Chatbot into a Website.

Sources

• Google Search Central: Site Moves and Migrations
• Google Search Central: Redirects and Google Search
• Google Search Central: Robots Meta Tags Specifications
• Microsoft Learn: Retrieval-augmented generation in Azure AI Search

Planning a website relaunch and want to migrate your chatbot’s knowledge base in a controlled manner? Define sources, test questions, and handoff rules before go-live. ChatReact helps you structure website content as a reliable foundation for multilingual conversations.