AI-chatbot bij een website-relaunch: staging, redirects en go-live-QA

Een website-relaunch verandert niet alleen het ontwerp, de navigatie en URL's. Het verandert ook de kennisbasis van een AI-chatbot. Nieuwe productpagina's vervangen oude paden, helpteksten verhuizen naar andere onderdelen en sommige inhoud verdwijnt helemaal. Als de bot tijdens deze overgang op een verouderde index blijft werken, geeft hij weliswaar vloeiende, maar mogelijk onjuiste of onvindbare antwoorden.

Daarom moet de AI-chatbot niet als een achteraf toegevoegde widget worden behandeld. Hij hoort thuis in het relaunchplan, net als redirects, de sitemap, analytics en formulieren. Bepalend is een gecontroleerde keten: bronnen inventariseren, staging helder afbakenen, nieuwe inhoud indexeren, antwoorden testen en pas daarna de datastatus vrijgeven voor productie.

Waarom de chatbot onderdeel moet zijn van het relaunchplan

Een klassieke relaunchtest controleert of pagina's laden, omleidingen (redirects) werken en formulieren verzonden kunnen worden. Bij een op RAG gebaseerde chatbot komt daar een tweede laag bij: welke tekstfragmenten worden gevonden, welke bron wordt geciteerd en past het antwoord noch wel bij de nieuwe paginastructuur?

Retrieval-Augmented Generation, kortweg RAG, verbindt een taalmodel met eigen inhoud. De zoekcomponent haalt passende tekstfragmenten op uit een index; het model formuleert op basis daarvan het antwoord. Microsoft beschrijft als centrale taken onder meer relevante in plaats van uitputtende resultaten, actuele indexering en gecontroleerde toegang tot bronnen. Voor een relaunch betekent dit: een correcte redirect in de browser werkt de chatbot-index niet automatisch bij.

Plan daarom drie samenhangende datastromen. De webserver leidt oude URL's om. Zoekmachines ontvangen canonicals, statuscodes en een actuele sitemap. De chatbot krijgt een nieuw opgebouwde of gericht bijgewerkte kennisbasis. Pas wanneer alle drie de niveaus naar dezelfde doelpagina's wijzen, is de verhuizing consistent.

Staging veilig en realistisch voorbereiden

Preview beschermen zonder de test te beïnvloeden

De staging-website mag niet per ongeluk openbaar worden geïndexeerd. Voor reguliere zoekmachines kunnen noindex of een overeenkomstige X-Robots-Tag extra beschermingslagen bieden. Google wijst er echter op dat een noindex-instructie alleen gelezen kan worden als de crawler de pagina mag ophalen. Voor echt vertrouwelijke staging-inhoud zijn toegangsbeveiliging en autorisaties daarom belangrijker dan alleen een robots-regel.

De chatbot-crawler heeft desondanks gecontroleerde toegang nodig. Gebruik daarvoor gescheiden inloggegevens, een duidelijk gedefinieerde allowlist en een eigen staging-index. Zo voorkomt u dat concepten in productieve antwoorden terechtkomen. Tegelijkertijd kan de bot worden getest met realistische navigatie, pdf's en gestructureerde inhoud.

Configuraties strikt scheiden

Staging en productie mogen niet dezelfde index, webhook of analytics-datastroom gebruiken. Wijs eenduidige namen toe en controleer voor elke testrun naar welk doel de betreffende configuratie wijst. Een eenvoudige vrijgavelijst moet minimaal de domeinnaam, crawl-startpunten, toegestane bestandstypen, uitsluitingen, indexnaam en de verantwoordelijke persoon bevatten.

Bijzonder belangrijk zijn formulieren en overdrachten naar medewerkers (human handoff). Een testchat mag geen echte leads naar sales sturen en geen productieve supporttickets aanmaken. Gebruik gemarkeerde testdoelen en controleer de human handoff als een afzonderlijk proces.

URL-mapping en bronneninventaris samen beheren

Google raadt bij websitemigraties met gewijzigde URL's een nauwkeurige koppeling van oude aan nieuwe adressen en permanente server-side omleidingen aan. Voor de chatbot moet dezelfde mappinglijst worden aangevuld met kennisvelden. Daardoor verandert een SEO-tabel in een gezamenlijk sturingsinstrument voor web, content en AI.

Leg per relevante bron minimaal het volgende vast:

• oude en nieuwe URL alsmede de verwachte HTTP-status,
• paginatype, taal en inhoudelijke verantwoordelijkheid,
• of de bron geldig blijft, wordt vervangen of verwijderd,
• of deze in de chatbot-index mag worden opgenomen,
• welke testvragen de bron moet afdekken.

Leid een oude pagina niet zonder meer om naar de homepage. De nieuwe doelpagina moet inhoudelijk aansluiten. Voor permanent verplaatste inhoud zijn permanente redirects het juiste signaal; Google noemt server-side 301- en 308-redirects als permanente varianten. Verwijderde inhoud zonder echte vervanging moet niet kunstmatig naar een ongeschikte pagina wijzen.

Controleer bovendien interne links, canonicals en de sitemap. De chatbot-crawler moet direct de nieuwe doel-URL's opnemen, in plaats van continu via oude adressen te lopen. Dat vermindert onnodige verzoeken en maakt bronvermeldingen in antwoorden duidelijker.

De kennisbasis gecontroleerd opnieuw opbouwen

Een relaunch is een goed moment om het kennisbestand op te schonen. Verwijder dubbele concepten, verouderde pdf's en pagina's die alleen voor campagnes of interne testen bedoeld waren. Definieer vervolgens de toegestane startpunten en uitsluitingen voor de crawl. Een handleiding hiervoor vindt u in het artikel KI-Chatbot-Wissensbasis aktuell halten.

Bij het indexeren moeten koppen, alinea's, lijsten en tabellen op een logische manier in fragmenten worden opgedeeld. Te grote tekstblokken leveren vaak te veel context, zeer kleine fragmenten verliezen hun betekenis. Microsoft noemt chunking, vectorisatie en hybride zoeken als bouwstenen van klassieke RAG-pipelines. Bepalend is echter niet alleen de methode, maar of de relevante nieuwe inhoud bij echte gebruikersvragen betrouwbaar wordt gevonden.

Voer de eerste volledige crawl uit in de staging-index en log foutpagina's, geblokkeerde bestanden en ongewoon kleine of grote documenten. Start daarna een tweede, incrementele run. Zo controleert u of wijzigingen daadwerkelijk worden opgemerkt en of verwijderde inhoud uit de index verdwijnt.

Een Golden Set maken voor de relaunch-QA

Een steekproef met een paar vriendelijke vragen is niet genoeg. Maak een Golden Set op basis van reële zoekintenties en verwachte kernboodschappen. Hoe u dergelijke testen gestructureerd beoordeelt, leest u in de gids KI-Chatbot-Antwortqualität messen.

Voor de relaunch moet de set verschillende risicoklassen bevatten:

• vragen over wichtige producten, diensten, prijzen en voorwaarden,
• vragen waarvan het antwoord naar een nieuwe URL is verhuisd,
• vragen over bewust verwijderde of samengevoegde inhoud,
• dubbelzinnige formuleringen en typische typfouten,
• vragen in alle daadwerkelijk aangeboden talen,
• gevallen waarin de bot geen zeker antwoord mag geven.

Beoordeel niet alleen de bewoording. Controleer of de juiste bron is opgehaald, of links naar het nieuwe domein en het correcte taalpad wijzen en of getallen, datums en productnamen exact zijn overgenomen. Een mooie zin met een oude URL is geen geslaagde test.

Routing, formulieren en handoff afzonderlijk testen

Veel chatbots beantwoorden niet alleen vragen, maar kwalificeren ook aanvragen of dragen gesprekken over. Na een relaunch kunnen nieuwe formuliervelden, andere events of gewijzigde routingregels ongemerkt kapotgaan. Test daarom minimaal één succesvol en één afgewezen proces per belangrijk doel. Controleer bovendien of toestemmingsteksten zichtbaar zijn en of verzonden gegevens in het juiste systeem terechtkomen.

Bij meertalige websites moet elke taal als een eigen gebruikerspad worden gecontroleerd. Een werkende Duitse dialoog bewijst niet dat Franse links, Kroatische bronnen of Engelse overdrachtsteksten kloppen.

Go-live in een gecontroleerde volgorde

Het daadwerkelijke omschakelmoment moet kort en helder zijn. Bevries contentwijzigingen gedurende een duidelijk gedefinieerd tijdsbestek, exporteer de definitieve URL-mapping en documenteer de goedgekeurde indexstatus. Daarna kan de nieuwe website worden gepubliceerd en de redirectlogica worden geactiveerd.

Een praktische volgorde is:

1. Productie opleveren en basispaginaweergaven controleren.
2. Redirects, canonicals, sitemap en robots-signalen controleren.
3. De productieve chatbot-index opbouwen met de goedgekeurde bronnen.
4. De Golden Set uitvoeren op de productie-omgeving.
5. Formulieren, analytics en human handoff controleren met gemarkeerde testgevallen.
6. Pas daarna de chatbot zichtbaar maken voor alle bezoekers.

Als de chatbot tijdens de verhuizing al zichtbaar moet blijven, is een beperkte modus verstandig: alleen stabiele onderwerpen beantwoorden, bij onzekere vragen transparant wijzen op de lopende update en een menselijke contactmogelijkheid bieden. Verzin geen tijdelijke tusseninformatie.

Na de relaunch: foutpatronen gericht monitoren

In de eerste dagen moet het team niet alleen paginaweergaven in de gaten houden. Relevant zijn ook onbeantwoorde vragen, de fallback-ratio, kliks op bronnen, veelvoorkomende oude URL's en gesprekken die onverwacht aan medewerkers worden overgedragen. Deze signalen laten zien waar de mapping of kennisbasis nog hiaten vertoont.

Controleer steekproefsgewijs de meest gebruikte antwoorden handmatig. Als de bot naar een oude URL verwijst, kan de oorzaak in het opgeslagen document, in de index of in een hardgecodeerde antwoordsjabloon liggen. Corrigeer de bron, voer een gerichte herindexering uit en herhaal dezelfde testcase. Een algehele hergeneratie van alle inhoud maakt het opsporen van fouten juist moeilijker.

Plan bovendien de ontmanteling van staging-toegangen en test-webhooks in. Niet meer benodigde inloggegevens moeten worden gedeactiveerd, tijdelijke allowlist-vermeldingen worden verwijderd en testindices duidelijk worden gearchiveerd of verwijderd. Zo blijft de relaunch-infrastructuur niet ongemerkt achter als een permanent aanvalsoppervlak.

Korte relaunch-checklist voor websiteteams

• Chatbot-verantwoordelijken zijn benoemd in het relaunchplan en het vrijgaveproces.
• Staging is beveiligd met toegang en gescheiden van de productieve index.
• Oude en nieuwe URL's zijn gemapped met bronstatus en testvragen.
• Crawl-regels, talen, pdf's en uitsluitingen zijn gecontroleerd.
• De nieuwe index is volledig en vervolgens incrementeel getest.
• De Golden Set dekt kernvragen, oude URL's, negatieve scenario's en handoff af.
• Alle links, getallen, namen en taalpaden in de antwoorden kloppen.
• Monitoring en verantwoordelijkheden voor de periode na de go-live staan vast.

Wie de chatbot als een afzonderlijke relaunch-workstream behandelt, voorkomt verouderde antwoorden en onduidelijke bronnen. Tegelijkertijd ontstaat er een gestructureerd proces dat bij latere contentwijzigingen opnieuw kan worden gebruikt. Tips voor de technische integratie vindt u ook in het artikel KI-Chatbot in eine Website einbinden.

Bronnen

• 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

Plant u een relaunch en wilt u de kennisbasis van uw website-chatbot gecontroleerd verhuizen? Definieer bronnen, testvragen en overdrachtsregels voor de go-live. ChatReact helpt u bij het structureren van website-inhoud als transparante basis voor meertalige dialogen.