Relaunch-controlelijst voor online shops, boekings- en bedrijfswebsites.

Plan je relaunch zorgvuldig en zorg voor een succesvolle realisatie met behulp van een checklist. Stel jezelf vooral ook de twee doelen, enerzijds om je online zichtbaarheid te behouden en anderzijds om mogelijkheden te vinden om in het kader van de relaunch de basis te leggen voor een verhoging van de online zichtbaarheid. Precies daarvoor is dit artikel bedoeld, om je een relaunch-gids te geven, zodat je risico's bij de relaunch beperkt blijven en je daadwerkelijk een buitengewoon goed resultaat met het potentieel van duurzaam, organisch SEO-succes behaalt.

Stappenplan voor een relaunch

De planning van een website-relaunch moet zorgvuldig worden uitgevoerd. Het is belangrijk om de volgende stappen te overwegen:

• Analyse van de bestaande website en het documenteren van de huidige situatie: Allereerst moet de bestaande website worden geanalyseerd om de sterke en zwakke punten te identificeren.
• Doelen vaststellen: De doelen van de website-relaunch moeten duidelijk worden gedefinieerd. Dit omvat bijvoorbeeld het verbeteren van de conversieratio, het verhogen van het aantal bezoekers of de overstap naar een nieuw CMS met verbeterd contentbeheer en onderhoudbaarheid.
• Ontwikkelen van een concept: Op basis van de analyse en de doelen, evenals een concurrentieanalyse, moet er een concept worden ontwikkeld voor de website-relaunch. Het concept moet de volgende aspecten omvatten: design, inhoud, technologie en SEO/marketing.
• Uitvoering: Het concept wordt vervolgens uitgevoerd. Dit omvat het ontwikkelen van het design, het maken/aanpassen van de inhoud en het doorvoeren van technische veranderingen.
• Testen: De nieuwe website moet grondig worden getest voordat deze wordt gelanceerd, om ervoor te zorgen dat deze foutloos werkt. Dit omvat ook een gedefinieerde checklist.
• Lanceren: De nieuwe website wordt dan gelanceerd. En er wordt verder live getest, geëvalueerd en aangepast.

Vaststellen van de doelen en de strategie van de relaunch

Bepaal precies welke doelen de relaunch nastreeft. Doelen kunnen zijn (naast de eerder genoemde redenen): 

• Verbetering van de gebruikerservaring
• Verhoging van de overzichtelijkheid
• Uitbreiding van het aanbod van inhoud
• Modernisering van het design
• Verhoging van de omzet en de gemiddelde orderwaarde 
• Overschakelen naar een ander CMS met eenvoudiger contentbeheer en technische onderhoudbaarheid
• Op termijn makkelijkere uitbreidbaarheid en behoud van updatebaarheid.

Voorgesteld: Na de eerste kick-off vergaderingen in het team als bedrijf – nog voordat de gesprekken met uitvoerende bureaus beginnen – zou elke projectdeelnemer de doelen van jullie relaunch op een briefje moeten schrijven of in zijn invoerveld in jullie communicatietool (bijv. Slack) moeten typen. Als dan iedereen tegelijkertijd zijn genoemde doelen laat zien, zul je verrast zijn hoe verschillend de meningen zijn, ook al was het doel al besproken in de vergaderingen. Daarom is het belangrijk om de doelen ook schriftelijk vast te leggen. Als je je doelen precies kent, kun je al in een vroeg stadium de UI-prototype controleren om te zien of deze conceptueel zijn meegenomen.

Opstellen van een eisenpakket voor duidelijkheid over de relaunch-opdracht

Om een ​​uitgebreide offerte te kunnen maken, heeft het bureau een uitgebreide projectbriefing nodig van de klant. Bedrijven hebben meestal een Word-document of een PDF bij de hand waarin het project min of meer gedetailleerd wordt geschetst. Dan zijn er vragenlijsten of worden er workshops gehouden waarmee bureaus de pijnplekken bij de klant beter kunnen benadrukken om een offerte te kunnen uitbrengen. Bij grotere projecten wordt een lastenheft opgesteld. Hoe gedetailleerder, hoe beter. 

Een lastenheft is een document dat een cruciale rol speelt bij een website-relaunch. Het dient om de eisen, doelen en verwachtingen van de relaunch schriftelijk vast te leggen. Een goed uitgewerkt lastenheft helpt ervoor te zorgen dat alle betrokkenen – of het nu het ontwikkelingsteam, het designteam of de klant is – een duidelijk begrip hebben van wat tijdens de relaunch moet worden bereikt. Het is ook de basis voor een goed berekende en bindende offerte van het uitvoerende bureau. Hier zijn informatie en elementen die normaal gesproken in een lastenboek voor een website-relaunch kunnen worden opgenomen:

• Doelen en doelstellingen: Een beschrijving van de belangrijkste doelen van de relaunch, zoals het verbeteren van de gebruikerservaring, het verhogen van de zichtbaarheid in zoekmachines of de overstap naar een CMS met een geactualiseerd design.
• Projectomvang: Een duidelijke definitie van wat wel en niet is inbegrepen in de relaunch. Dit kan het aantal pagina's, de integratie van tools van derden of de herziening van inhoud omvatten.
• Designvereisten: Informatie over het gewenste visuele ontwerp van de website, inclusief lay-outs en de naleving van de richtlijnen voor de huisstijl met betrekking tot kleuren, lettertypen en afbeeldingen.
• Functionaliteitseisen: Een specificatie van de gewenste functies en interacties op de website, zoals contactformulieren, zoekfuncties, e-commerce functies, enz.
• Technische vereisten: Specificaties voor de technologieën die tijdens de relaunch moeten worden gebruikt, zoals de keuze van een content management systeem (CMS) of de implementatie van bepaalde functies. Ook het gebruik van moderne beeld- en grafiekformaten (WebP, AVIF, SVG) valt hieronder.
• Handmatige en automatische back-ups en revisies van inhoudsbewerkingen.
• Inhoudsvereisten: Duidelijke richtlijnen voor het herzien, updaten of opnieuw maken van inhoud, inclusief teksten, afbeeldingen, video's en andere media. Metadata- en gestructureerde gegevensverwerking.
• SEO-eisen: meer hierover in het volgende inhoudsgebied.
• Tijdlijn en mijlpalen: Een planning die de geplande begin- en voltooiingsdata van de relaunch en belangrijke mijlpalen vastlegt.
• Budget: Informatie over het budget voor de relaunch, inclusief kosten voor design, ontwikkeling, hosting en eventuele diensten van derden.
• Kwaliteitsborging met testtools: Beschrijving van de tests en kwaliteitscontroleprocedures die tijdens de relaunch moeten worden uitgevoerd om ervoor te zorgen dat de website correct werkt.
• Onderhouds- en ondersteuningsvereisten: Vereisten voor het doorlopend onderhoud en de ondersteuning van de website na de relaunch.

Een goed gestructureerd lastenboek is essentieel om misverstanden te voorkomen, het project efficiënt te beheren en ervoor te zorgen dat aan de verwachtingen van alle belanghebbenden wordt voldaan. Het dient als richtlijn en referentiedocument voor het hele projectteam en draagt bij aan het waarborgen van het succes van de website-relaunch. 

Terwijl we onze relaunch van TutKit.com planden met een volledige overschakeling van het framework van CodIgniter naar Laravel, omvatte ons lastenboek 220 pagina's - (geen) verleidelijk voor een bureau om doorheen te werken.

Opmerking: In mijn artikel wordt niet gedetailleerd ingegaan op concept, ontwerp, functionaliteit en gebruikte technologie. De nieuwe website zal er zeker mooi uitzien. Het grootste gevaar bij een relaunch ligt eigenlijk in een verslechtering van de technische gebruikerservaring en de OnPage-kwaliteit door het ontbreken van 301-redirects, wat kan leiden tot verlies van rangschikking en zichtbaarheid. Om dit te voorkomen, wordt in het volgende met name de focus gelegd op het verzekeren van het project succes vanuit gebruikerservarings- en SEO-perspectief.

Definitie van de SEO-vereisten voor de nieuwe website

De briefing van de klant of een uitgebreider lastenboek regelt al wat er op het gebied van ontwerp, inhoud, functionaliteit en techniek wordt verwacht en vormt de basis voor een bureau om een offerte op te stellen.

Voor de Relaunch-Checklist ter borging van het project succes moet vanuit SEO-perspectief naar de verschillende passages worden gekeken. Er ontstaan specifieke SEO-vereisten door bijvoorbeeld:

• een veranderende URL-structuur (URL-redirectkaart!) en veranderende linkpaden
• een veranderende navigatie (belangrijk vanwege interne linkbuilding en linkhiërarchie)
• veranderende technologieën (CMS, JavaScript-framework, server, …)
• veranderende inhoud (mogelijk verlies van zichtbaarheid van goedgerangschikte pagina's)

Pagina's scoren goed in Google vanwege hun inhoudelijke relevantie, daarom zijn vragen belangrijk, bijvoorbeeld of bestaande inhoud verandert of samengevoegd wordt, of inhoud verdwijnt en/of nieuwe inhoud wordt toegevoegd? Verandert de inhoudelijke structuur van categorieën of pagina's? Uit deze punten moeten SEO-vereisten worden afgeleid die in de Relaunch-Checkliste moeten worden opgenomen.

Worden de metagegevens van de oude inhoud ook overgedragen en veranderen ze? Hoe wordt de contentonderhoud door de bewerker uitgevoerd en zijn de pagina-inhoud gelinkt met gestructureerde gegevens?

Worden de bestaande of nieuwe afbeeldingen in moderne beeldformaten voor websites (WebP/Avif) opgeslagen en wordt er gelet op beeld-SEO met sprekende URL's in kleine letters, dus in plaats van 1234.jpg => hotel-ostsee-warnemuende_suite-nachtigall.avif.

Evenzo moet ervoor worden gezorgd dat beeldbestanden met gestructureerde gegevens (ImageObject) en <meta>-thumbnails aan Google worden doorgegeven om de kans op de insluiting van beelden in de zoekopdrachtfragmenten en de vermelding op Google Afbeeldingen te vergroten.

Ook interessant in dit verband is de vraag hoe gebruikersignalen verbeterd kunnen worden. Op inhoudspagina's kunnen bijvoorbeeld beeldvideo's, uitleg- en helptaken-video's worden ingebed. Wanneer een gebruiker die vanuit Google naar de landingspagina komt op de video klikt en deze bekijkt, stijgt de tijd dat hij op de pagina blijft (goed gebruikersignaal), ook verbetert de retour-naar-SERP-snelheid (goed gebruikersignaal). 

Ook moet worden onderzocht hoe inhoudelijke secties op de pagina's worden geïntegreerd die voldoen aan de vereisten van Google voor Nuttige Inhoud en voor het E-A-T-principe.

Volgens Google is "Nuttige Inhoud" inhoud die relevant en nuttig is voor gebruikers. Het beantwoordt de vragen van gebruikers volledig en informatief, biedt oplossingen voor problemen en biedt toegevoegde waarde die verder gaat dan louter reclameboodschappen.

Hier zijn enkele voorbeelden van nuttige inhoud:

• Tutorials en handleidingen: Deze inhoud helpt gebruikers bij het leren van nieuwe taken of het oplossen van bestaande problemen.
• Recensies en vergelijkingen: Deze inhoud helpt gebruikers bij het kiezen van het juiste product of dienst.
• Nieuws en updates: Deze inhoud houdt gebruikers op de hoogte van recente gebeurtenissen en trends.
• Infographics en diagrammen: Deze inhoud kan helpen complexe gegevens en informatie te visualiseren.
• Blogposts en artikelen: Deze inhoud biedt een dieper inzicht in een specifiek onderwerp.

Google gebruikt verschillende signalen om nuttige inhoud te herkennen. Hieronder vallen onder andere:

• Gebruikersgedrag: Google observeert hoe gebruikers met inhoud omgaan, bijvoorbeeld hoe lang ze op een pagina blijven, hoe vaak ze deze delen en hoe vaak ze deze beoordelen.
• Kwaliteitssignalen: Google beoordeelt de kwaliteit van inhoud op basis van factoren als relevantie, volledigheid en actualiteit.
• Feedback van gebruikers: Google houdt ook rekening met feedback van gebruikers, zoals beoordelingen en opmerkingen.
• Door het overwegen van deze signalen kunnen websitebeheerders hun kansen vergroten dat hun inhoud wordt beschouwd als nuttig.

Het EEAT-principe is een concept ontwikkeld door Google dat de kwaliteit van websites en webinhoud beoordeelt. Het staat voor Deskundigheid, Ervaring, Autoriteit en Betrouwbaarheid, dus Deskundigheid, Ervaring, Autoriteit en Betrouwbaarheid.

• Deskundigheid verwijst naar de kennis en ervaring van de personen die de inhoud creëren. Google beoordeelt deskundigheid op basis van factoren zoals opleiding, werkervaring en onderscheidingen.
• Ervaring wordt erkend wanneer de inhoud ook is gemaakt met een zekere ervaring, bijvoorbeeld gebaseerd op daadwerkelijk gebruik van een product, daadwerkelijk bezoek aan een locatie of beschrijving van de ervaringen van een persoon?
• Autoriteit heeft betrekking op de reputatie van een website of webinhoud. Google beoordeelt de autoriteit op basis van factoren zoals backlinks, activiteiten op sociale media en gebruikersbeoordelingen.
• Betrouwbaarheid heeft betrekking op de betrouwbaarheid en geloofwaardigheid van een website of webinhoud. Google beoordeelt de betrouwbaarheid op basis van factoren zoals privacy, beveiliging en transparantie.

Welke SEO-eisen hebben bestaande en nieuwe functionaliteiten met betrekking tot frontend en backend? Hier gaat het bijvoorbeeld om:  

• Crawlbaarheid (relevante inhoud moet ook zonder JavaScript zichtbaar en crawlbaar zijn)
• Duidelijkheid over het doel van de website en duidelijkheid over de call-to-action (het gewenste gedrag van de doelklant op de pagina's)
• Vermijden van dubbele inhoud door bijvoorbeeld automatisch aangemaakte categoriepagina's of paginaduplicaten door variantartikelen
• Zorgen voor een hoge PageSpeed door het vermijden van te veel JavaScript- en CSS-bestanden, door het gebruik van moderne beeldformaten (WebP/AVIF)

Deze SEO-eisen moeten worden opgenomen in de projectbriefing of specificatie, maar ook via een checklist gerelateerd aan testtools of als IST-SOLL-vergelijking in de kwaliteitsborging van het project en bovendien als acceptatiecriterium voor de prestaties van het bureau. Meer informatie hierover onderaan.

Vaststelling van interne en externe projectbetrokkenen

Bepaal de projectbetrokkenen - hier vanuit het perspectief van de klant of website-eigenaar: 

• Wie is verantwoordelijk voor het projectmanagement en neemt de uiteindelijke beslissingen? 
• Wie is verantwoordelijk voor de coördinatie en communicatie met het bureau of de klant? 
• Wie neemt het interne projectmanagement op zich?
• Wie bereidt intern de inhoud voor en ondersteunt het bureau?
• Wie voert het user experience design uit? 
• Wie voert de ontwikkeling uit? 
• Wie rapporteert namens het bureau aan de klant op welke vooraf bepaalde intervallen?
• Wie voert de test- en kwaliteitsborging uit namens het bureau/klant?
• Wordt er een externe consultant ingeschakeld (bijv. voor SEO of juridische vereisten)?
• Wie keurt taken goed? Wie controleert de taken in het ticketsysteem na voltooiing?
• Wie moet op welk moment op de hoogte worden gebracht (medewerkers, klanten, partners, AdCampagnebeheerders, …) 

Bij de selectie van externe projectbeheerders zijn vier punten belangrijk

1. Heeft het bureau een of meerdere projecten van deze aard gerealiseerd? Zijn er referenties? Bestaan er klantbeoordelingen en zou ook een feedbackgesprek met klanten van het bureau mogelijk zijn - wat aan te bevelen is bij grotere individuele ontwikkelingen?
   
2. Voldoen zowel de dienstverlening als de technische uitvoering (CMS/Shopssysteem/Framework) reeds aan alle vereisten die verband houden met de herlancering? Moeten er nog individuele functies of vereisten worden geprogrammeerd (ook via plug-in of module)? Worden specifieke diensten uitgesloten of voor een later tijdstip gereserveerd, die echter cruciaal zijn voor het succes van het project? Het is belangrijk dat er geen nieuwe problemen ontstaan die groter zijn dan de werkelijke reden voor de herlancering.
   
3. Past het uitvoerende bureau zowel qua teamgrootte als regionale locatie en (eventueel via Kununu-beoordelingen te bepalen) personeelsverloop op de lange termijn bij het bedrijf?
   
4. Is er een direct contact met het uitvoerende ontwerp- en ontwikkelingsteam mogelijk? Het is handig om het daadwerkelijke team van het bureau aan de agentiekant te leren kennen. De goed gehumeurde en hemelbestormende salesprofessionals krijgen de opdracht en zijn daarna niet meer verantwoordelijk. Daarom moet ook een direct contact met het uitvoerende team worden overeengekomen.

Vier tips voor uw eigen beveiliging in dit verband

1. Als klant zou ik goed letten op de gebruikte technologie van het bureau. Wat in de aanbieding staat, gewoon even googelen met "CMS + nadelen" of "CMS + ervaringen". U moet weten waar u precies aan begint. Het is verstandig om te kiezen voor open-source-oplossingen. Ik begrijp dat dit niet altijd mogelijk is. Zorg er bij voorkeur voor dat er een zo groot mogelijke gemeenschap van ontwikkelaars voor de gebruikte technologie is, zodat u uiteindelijk niet eindigt met een oplossing die alleen uw bureau kan verwerken, wat u op een bepaalde manier later in aanzienlijke knel kan brengen.
   
2. Let er ook op dat u het onbeperkte gebruiks- en bewerkingsrecht van de dienstverlening van het bureau krijgt, zodat u altijd het recht heeft om de website intern of extern verder te ontwikkelen. Zo'n clausule hoort thuis in het werkpakket.
   
3. Als uw bedrijf technisch wat meer onderlegd is en u systeembeheerders, softwareontwikkelaars of iets dergelijks in het team heeft, is het zinvol om GIT voor versiebeheer en JIRA (of een vergelijkbare tool) voor projectmanagement of ticketsysteem voorlopig zelf op te zetten in een eigen account. Vervolgens geeft u het bureau volledige toegangsrechten en kunnen de werkzaamheden beginnen. Hoe groter een project is, hoe ruwer en pijnlijker het kan worden. Het is goed als u de beschikkingsmacht heeft over de essentiële toegangen en accounts. Ik begrijp echter dat deze aanbeveling vanuit puur vakinhoudelijk oogpunt slechts door enkelen klanten kan worden opgevolgd.
   
4. Het komt soms voor dat bureaus hosting direct aanbieden aan klanten. Wij zijn daar zelf geen fan van, omdat het enerzijds de afhankelijkheid in de klantrelatie vergroot en anderzijds vinden we dat webhosters het meest geschikt zijn voor webhosting, omdat ze zich daarop hebben gespecialiseerd. We hebben ook al servers voor onszelf opgezet en beheerd en hebben veel personele en tijdige middelen verspild. We zijn weer teruggekrabbeld. Nu draaien onze systemen op cloudservers van een van de grote webhosters in Duitsland en we zijn gelukkig. Let bij webhosting in ieder geval op de aanwezigheid van server-side back-ups in het pakket die met een paar klikken kunnen worden geïmplementeerd.

Bepaling van de duur en de lanceerdatum

Een herlancering wordt uitgevoerd in meerdere project-sprints. Deze kunnen naar onze agentuurervaring als volgt zijn:

• Huidige situatie wordt vastgelegd (via testtools, maar ook schriftelijk met indrukken van wat goed werkt aan de kant van de klant en waar verbeteringen nodig zijn)
• Onderzoeksfasen met concurrentieanalyse en onderzoek naar oplossingen/inspiratie
• Draadmodel ontwerp
• Ontwerp van de gebruikersinterface
• Frontend- en backend-ontwikkeling
• Migratie van gegevens of inhoudsimport (geautomatiseerd/handmatig)
• Structurele en inhoudelijke optimalisatie van content (tekst en beeld) & SEO-sprint

Project-sprints overlappen elkaar omdat gedurende de bewerking nieuwe projectdeelnemers actief worden.

Belangrijk is om de duur van de individuele project-sprints te definiëren en af te stemmen met de betrokkenen. 

Richt de agentuur voor de klant voor het project, indien het groter is, een eigen Slack-kanaal in voor snellere communicatie?

Een tip op dit punt: Het is goed als het bureau al in een zeer vroeg stadium met klikbare prototypes werkt, dus al in het draadmodelontwerp en zeker bij de presentatie en de beoordeling van het gebruikersinterfaceontwerp. Op deze manier krijgen klanten een beter gevoel van de ervaring van de website. Eenvoudige JPG- of PNG-bestanden als ontwerpvoorstel zijn vandaag de dag niet meer up-to-date. Het zouden klikbare prototypes moeten zijn, die met Sketch, Figma, Adobe XD of een ander professioneel tool worden gemaakt.

In deze vroege fase zijn wijzigingen makkelijk door te voeren. Als functies en secties van een website al zijn ontwikkeld, zijn wijzigingen veel ingewikkelder en kunnen ze mogelijk leiden tot onderhandelingen achteraf, wat absoluut niet aantrekkelijk is.

Hier is eens te zien hoe zo'n prototype voor het mobiele gebruikersinterfaceontwerp met de klikpaden er in het kort uitziet:

De vraag is wanneer lopende tests van klantzijde mogelijk zijn. Ontwikkelaars moeten hun lokale werk ook testen na samenvoeging in het stagingsysteem. Dat klinkt triviaal, maar iedereen die met ontwikkelaars samenwerkt, begrijpt meteen wat ik bedoel. Vervolgens zou degene die verantwoordelijk is voor de kwaliteitsborging aan de bureaukant het ticket of de functie moeten testen. Pas daarna wordt het ticket vrijgegeven voor de klantentest. De klant mag zich nooit als alfatester voelen, maar moet al een systeem vinden dat door vier ogen is getest. Het bureau is alfatester, de klant is bètatester! Is er eigenlijk toegang tot het ticketsysteem van het bureau?

Het moet ook schriftelijk worden vastgelegd dat rapporten van de bureauzijde aan de klant met een bepaalde frequentie moeten worden verstrekt. Bijvoorbeeld zou er elke vrijdag een rapport via e-mail moeten zijn over de huidige stand van zaken, de noodzakelijke feedbacklussen of ondersteuningsverzoeken. Dit is ook een tip uit onze agentuurervaring: Het is goed om de klant niet onzeker het weekend in te sturen. Hij komt dan alleen maar op domme ideeën. Liever goed informeren over wat er is gebeurd en wat er volgende week op de agenda staat. Transparantie helpt om ervoor te zorgen dat iedereen zich betrokken voelt en met een goed gevoel aanwezig blijft.

De lanceerdatum moet ook worden vastgelegd. Volgens de wet van Parkinson strekt het werk zich uit om de beschikbare tijd voor de voltooiing ervan te gebruiken. Met andere woorden, hoe meer tijd beschikbaar is voor de voltooiing van een taak, hoe meer tijd daarvoor wordt gebruikt, ongeacht de werkelijke complexiteit of inspanning. De geplande voltooiing moet ook in het contract worden vastgelegd. Het niet nakomen van de deadline kan zelfs worden voorzien van een boeteclausule in het contract. Als richtlijn geldt dat boetes van 0,2% van het contractbedrag per werkdag van vertraging en maximaal 5% van het contractbedrag effectief zijn. De boete hoeft dan niet per se te worden ingeroepen door de klant, maar geeft je wel de mogelijkheid om het bureau nog enkele extra verlangens als compensatie te ontlokken.

Belangrijk: Geen lancering op vrijdag. Ook niet tussen feestdagen of tijdens de piekuren van het bedrijf. Wij raden eigenlijk de nachtelijke uren van zondag op maandag aan voor grote herlanceringen, vooral als het IP-adres verandert, zodat de DNS-instellingen bij de meeste providers op maandag nog kunnen worden geüpdatet, wat vaak al aan het einde van de ochtend gebeurt, als het DNS-record in de nachtelijke uren is aangepast. Zo blijven er in feite nog 4,5 werkdagen over voor de live-test en bugfixes bij eventuele fouten.

Protocollering van de huidige status van je website

Het is noodzakelijk om de status quo vast te leggen voordat de werkzaamheden beginnen. De huidige status geeft aan hoe de technische meetresultaten zijn voor de parameters. Rechts daarvan kunt u de doelwaarden invullen:

In de lijst vind je als SEO-tool de door ons veel gebruikte Seobility voor het controleren van on-page factoren, waarvoor ik ook een SEO-training heb gepubliceerd. Er zijn veel soortgelijke tools zoals Sistrix, Semrush, Ryte, SE Ranking, Screamingfrog, enz. Het draait bij het SEO-tool vooral om het identificeren en oplossen van typische on-page fouten. Hierbij gaat het om de drie kerngebieden Techniek & Meta, Structuur en Inhoud, zoals Seobility de analyses opbouwt. Op vergelijkbare wijze vind je dit ook bij de andere SEO-tools. Het is belangrijk dat er altijd een volledige controle plaatsvindt, dus ALLE pagina's worden gecrawld en niet alleen de startpagina, en bovendien moet je een score of foutwaarde invoeren voor de huidige situatie en de streefwaarde die na de optimalisatie bereikt moet zijn. Bij Seobility is een waarde van 90 of hoger wenselijk. Evenzo vind je voor andere doeleinden alternatieve tools. Het is cruciaal dat er überhaupt een tool wordt gebruikt om uitstekende gegevens te waarborgen.

Dit is bijvoorbeeld onze huidige waarde voor de on-page kwaliteit:

De Gebruikerssignalen kunnen statistisch worden vastgelegd met meetwaarden uit Google Analytics 4 zoals de Bouncerate, Pagina's/Bezoekers, Duur van het bezoek, enz. Indien Google Analytics of een andere analysetool op een conforme manier wordt gebruikt, moeten deze gegevens ook worden opgenomen in de documentatie van de huidige situatie. 

Er moet ook een backlink-lijst worden aangemaakt, die bijvoorbeeld hier gratis kan worden gegenereerd: https://www.seobility.net/de/backlinkcheck/

Verder moet de oude sitemap.xml worden beveiligd, evenals een Volledige Backup van de site. Alle relevante pagina's moeten ook als lijst worden overgezet naar een Google Sheet, dat de basis vormt voor de URL-Redirect-Map. Een dergelijke CSV-lijst kan gemakkelijk worden geëxporteerd via een SEO-tool zoals Seobility. In de URL-Redirect-Map zijn alle relevante pagina's en gelinkte pagina's via externe backlinks (zie backlink-lijst) meegenomen, die later moeten worden doorgestuurd vanwege gewijzigde pagina-URL's. Verwijderde URL's moeten worden omgeleid naar de nieuwe URL's die overeenkomen met de oude. Het is belangrijk om Doorstuurketens te vermijden! De oude, nog bestaande doorverwijzingen moeten rechtstreeks naar de nieuwe eind-URL leiden. Ook moet worden gedacht aan de PDF-bestanden en afbeeldingen waar links naartoe zijn, zodat deze ook correct worden doorgestuurd en geen 404-link worden.

De doorverwijzingen worden ingesteld als 301-redirects op basis van de URL-Redirect-Map in de .htaccess, via Redirect-Maps via Vhost-configuratie of een databaseoplossing. De klant moet deze zelf kunnen beheren. Het is ook noodzakelijk dat de doorverwijzingen permanent zijn.

Evenzo is het aan te raden om elk paginatype te beveiligen met een volledige schermafbeelding. Dit is enerzijds een backup van het oude bestand, mochten er vragen rijzen na de lancering of er geen contenttypen zijn overgebracht, enzovoort.

Aan de hand van de bestaande pagina's, functies en inhoud en op basis van de meetresultaten kan worden benoemd wat al goed loopt en welk gebied geïdentificeerd wordt als potentieel voor optimalisatie, wat moet worden verbeterd door de herlancering.

Checklist: Voor de herlancering

Zodra het gebruikersinterface-ontwerp is bevestigd en het bureau zich in de ontwikkelsprint bevindt, wordt de volgende checklist relevant, die chronologisch tot aan de lanceringsdatum de belangrijkste punten opsomt:

1. Dev-omgeving met toegang voor alle betrokkenen beschikbaar is voor testen
2. Dev-omgeving staat op noindex
3. Toegang tot testtools in Dev-omgeving (IP-toelating of http-login) is ingesteld
4. Configuratie van de Dev-omgeving komt zoveel mogelijk overeen met die van het live-systeem
5. Site-structuur van de Dev-omgeving komt overeen met die van de toekomstige live-site
6. Data-migratie van oude gegevens is voltooid
7. Inhoudsaanpassingen zijn toegepast
8. SEO van afbeeldingen is toegepast
9. 301-redirects op basis van de URL-Redirect-Map zijn ingesteld 
10. On-page-controle met Seobility is uitgevoerd, fouten zijn opgelost, streefwaarden zijn behaald
11. Open Graph-gegevens zijn geldig
12. Gestructureerde gegevens zijn geldig
13. Controle van Pagespeed voor alle paginatypes is uitgevoerd, streefwaarden zijn behaald
14. Content-cookiebeleid werkt
15. Veiligheidskoppen zijn ingesteld
16. Toegankelijkheid is gegarandeerd, streefwaarden zijn behaald
17. Hreflang is geldig (bij meertalige sites)
18. Rechtsteksten (AGB, Impressum, Widerrufserklärung, Datenschutz) zijn bijgewerkt, DSGVO-conformiteit is gewaarborgd
19. Updates van CMS, frameworks, gebruikte plugins en modules naar de nieuwste versie zijn uitgevoerd
20. Definitieve cross-browser- en cross-device-functioneelheidstest toonde geen fouten aan
21. Definitieve status en lanceringsdatum zijn bekend
22. Volledige back-up is gemaakt

Het gebruik van gestructureerde gegevens (schema-markup) - zie punt 12 van de lijst - wordt vandaag de dag nog veel te weinig benadrukt. Maak je vertrouwd met het onderwerp en lees wat Google zegt over de markup voor gestructureerde gegevens in Google Zoeken. Google zal steeds meer waarde hechten aan geldige gegevens binnen de SGE, dus de door AI gegenereerde zoekresultaten. Ook het Helpful Content Update van Google vereist dat inhoud veel sterker wordt geverifieerd door expertice, ervaring, autoriteit en geloofwaardigheid. Gestructureerde gegevens vormen een deel van de oplossing om deze validatie voor Google te vereenvoudigen. Gebruik na het implementeren van gestructureerde gegevens de Schema-Markup-Validator, maar controleer ook je pagina's met de Structed Data Linter, dat ook door Google wordt aanbevolen en gelinkt in de PageSpeed Insights. Hiermee krijg je uitgebreidere informatie over codefouten met betrekking tot het gebruik van gestructureerde gegevens op je pagina.

Onder punt 16 komt nu voor het eerst Toegankelijkheid voor in dit artikel. Toegankelijkheid heeft al een eigen sectie in PageSpeed Insights en groene cijfers zijn wenselijk. De test of een pagina toegankelijk is of niet, moet naast PageSpeed Insights ook worden uitgevoerd via https://www.accessibilitychecker.org en/of https://wave.webaim.org. Vooral als er binnenkort een herlancering op de planning staat, moet dit punt verplicht worden meegenomen, omdat toegankelijkheid voor websites met de Wet ter versterking van digitale toegankelijkheid vanaf 2025 een actueel onderwerp wordt. Controleer met zo'n tool niet alleen de startpagina, maar elk type pagina - hetzelfde geldt voor de PageSpeed-tests!

Tijdens een herlancering zijn er vaak aanpassingen en updates bij de juridische teksten. Hier moet vroegtijdig aan worden gedacht, zodat de teksten eventueel via een specialist of via juridische generatoren beschikbaar worden gesteld. Ook moet worden gedacht aan verwerkersovereenkomsten, als bijvoorbeeld een nieuwe webhoster wordt gebruikt of als de nieuwsbriefdienst verandert. 

Punt 18 met de update van het CMS, de gebruikte JavaScript-bibliotheken, de geïnstalleerde modules en plugins wordt net zo onderschat als belangrijk. Een herlancering kan enkele maanden duren. Bij het WordPress-systeem is het gemakkelijk te zien dat er misschien al talloze updates beschikbaar zijn vóór de herlanceringsdatum. Klanten moeten ervoor zorgen dat de nieuwste versies bij de lancering worden gebruikt.  

Bij veranderende externe diensten komen er extra taken bij, die ook in de checklist moeten worden genoemd, zoals bij wijziging van de nieuwsbriefdienst: 

• Data-import van nieuwsbriefcontacten naar de nieuwe nieuwsbriefdienst
• Koppeling aan de nieuwsbriefdienst op de website bij het aanmeldformulier
• AV-overeenkomst
• Opstellen van nieuwe mailingtemplates
• en zo verder 

Tijdens de hele ontwikkelingssprints vinden uiteraard voortdurende tests van de functies etc. plaats. Het is verstandig om ook een uiterst gedetailleerde checklist te maken voor de tests, zodat er niets wordt vergeten. Het is niet voldoende om wat te klikken als uitvoerend bureau of als klant. Na onze herlancering van TutKit.com had onze acceptatiecontrolelijst zeker 1.000 regels. En zo doen we het nog steeds: na belangrijke grote updates controleren we ongeveer 70 interacties via een checklist voor Chrome, Safari en Android.

Checklist: De herlanceringsdag en de dagen erna

De herlanceringsdag is aangebroken en het is geen vrijdag en ook geen dag tussen de feestdagen. De nieuwe website gaat live, de DNS-instellingen zijn aangepast. Het is nu tijd om alles opnieuw te controleren en te evalueren. Controleer het volgende: 

1. robots.txt controleren, dat robots niet worden geblokkeerd 
2. Live-omgeving draait op index, follow.  
3. Canonical-tags zijn correct ingesteld
4. Pagina-broncode controleren op absolute paden (linkpaden van de testomgeving naar de live pagina)
5. Redirect van http naar https met/zonder www naar de bestemmingspagina op de startpagina en subpagina's functioneert
6. Testen van doorverwijzingen via de URL-Redirect-Map, evenals het controleren van de aanwezigheid van doorverwijzingstrajecten
7. OnPage-controle van de live-pagina met Seobility voor Techniek & Meta, Structuur en Inhoud ... met name de Noindex-pagina's controleren die via Seobility worden weergegeven
8. Open-Graph-gegevens zijn geldig
9. Gestructureerde gegevens zijn geldig
10. Controle pagina-snelheid voor alle paginatypes is voltooid, streefwaarden zijn bereikt
11. Cookiebeleid met toestemmingscookie-tool werkt zoals het hoort
12. Beveiligingsheaders zijn geconfigureerd
13. Toegankelijkheid is verzekerd
14. Hreflang controleren bij meertalige website controleren (https://app.sistrix.com/de/hreflang-validator)
15. Definitieve browser- en apparaatoverstijgende functionele test wees geen fouten uit
16. Nieuwe sitemap.xml indienen bij Google Search Console
17. Nieuwe bestemmingspagina's bijwerken bij de Google Ads-campagnes
18. Bij bepaalde domeinwijzigingen, denk aan links in sociale media, e-mailsignaturen, enzovoort

We gebruiken in onze ontwikkelomgeving MailHog om e-mails lokaal te testen. In dergelijke gevallen is het belangrijk dat de juiste SMTP-gegevens voor de ontvangst van e-mails in het live-systeem zijn ingesteld, zodat de e-mails ook daarheen gaan waar ze moeten zijn.

Bovendien moet worden gewaarborgd dat bij betalingsserviceproviders zoals Paypal het Sandbox is geïmplementeerd in het Dev-systeem, terwijl vervolgens natuurlijk de juiste verbinding moet worden gemaakt in het live-systeem.

In de dagen daarna is het vooral belangrijk om de Google Search Console in de gaten te houden. Het meest interessante is natuurlijk hoe jouw ranglijsten veranderen. Leg de focus met name op onverwachte veranderingen en foutmeldingen:

1. Crawlen: Hoststatus … Ophalen robots.txt, DNS-oplossing, serververbinding
2. Crawlstatistieken … Aanvragen, downloadgrootte, gemiddelde responstijd
3. Klikken in de SERP's
4. Weergaven in de SERP's
5. Gemiddelde CTR in de SERP's
6. Gemiddelde SERP-positie
7. Succes van Core Web Vitals 

Vooral wijst de Google Search Console u op fouten zoals bijv. URL-fout, Href-Lang-fout, pagina-indexering met spread geïndexeerd/niet geïndexeerd. Voor niet geïndexeerd moet er een reden zijn (doorverwijzing, noindex)...). Daar zie je ook dubbele inhoud of andere problemen. Als de Search Console problemen meldt met de gestructureerde gegevens of Core Web Vitals, onderzoek dat dan. Pas door de Live-gegevens kom je er bijvoorbeeld achter dat pagina's van jou ondanks een hoge PageSpeed problemen hebben met de Core Web Vitals, bijvoorbeeld vanwege CLS-fouten. Hier is goed te zien welke sprongen mogelijk zijn bij wijzigingen aan de website:

U kunt direct de slechte of te optimaliseren URL's laten zien. Neem een URL en voer een PageSpeed-test uit met behulp van PageSpeed Insights. Daar krijgt u dan de aanwijzingen waarom de Core Web Vitals niet worden voldaan en wat u kunt doen om de fouten te verhelpen. Vouw voor meer informatie de kleine pijl aan de rechterkant naar beneden. Over het algemeen kunnen deze aanbevelingen alleen worden geïmplementeerd door ontwikkelaars. Het is echter belangrijk dat je in staat bent om de problemen te identificeren om ze vervolgens met behulp van jouw bureau aan te pakken.

Waardeer ook uw gegevens uit uw analysetools, zoals bijvoorbeeld van Google Analytics 4. Houd ook de meetwaarden in de gaten die u systeemmatig kunt verzamelen, zoals bijvoorbeeld reserveringen, conversieratio, winkelwagenwaarde, aankopen/omzet per dag, aantal nieuwsbrief aanmeldingen, contactverzoeken, downloads van specifieke inhoud of video-weergaven. 

De Crawling-statistieken in Google Search Console zijn essentieel voor de controles in de dagen daarna. U vindt deze in de instellingen links in het menu. Er moet direct meer crawlfrequentie zichtbaar worden. Zo niet, zijn er crawl-fouten?

De hoststatus toont u direct fouten, zoals hier te zien is na een herlancering, toen crawlanfragen voor robots.txt zijn mislukt en ook de serververbinding op sommige momenten steeds weer verbroken was:

Ook interessant is wat de crawlanalyse aantoont. Na een herlancering is er doorgaans een opleving in de crawlanfragen. Daar kun je ook zien of er nog 404-pagina's worden gecrawld. Als sommige niet passen, bespreek dit dan met de ontwikkelaars.

Je ziet of je server, je PageSpeed en je code relatief goed zijn als je paginareactietijd onder de 400 ligt. Hoe dichterbij deze bij 1000 ms komt, hoe meer aanbevolen een PageSpeed-optimalisatie is, bijvoorbeeld door het verminderen van databasequeries en het versterken van de serverkracht (bijv. meer rekencapaciteit, updaten naar de nieuwste serversoftware, overschakelen naar HTTP2 of HTTP3 (bij Nginx)).

Perspectief wordt het crawl-budget voor individuele websites waarschijnlijk beperkter door steeds meer (KI-) inhoud op websites, dus hier zou ook naar gestreefd moeten worden naar een goede waarde bij de paginantwoordtijd, zodat de bots zoveel mogelijk kunnen crawlen op jouw pagina's in de beschikbare tijd.

Herlancering-checklist om te downloaden

De bovengenoemde checklisten voor de herlancering zijn ook beschikbaar als PDF-bestand voor jou om te downloaden. Download ze en zorg ervoor dat je project een succes wordt!

Bekentenissen van een bureauhouder

De SEO-eisen in de checklist kunnen ook gedetailleerde instructies bevatten zoals aandacht voor de kopstructuur van H1 tot H6 enz. De vaststelling van streefwaarden in de testtools verkort gelukkig inhoudelijk de hele herlancering-checklist, omdat het bereiken van topwaarden van de testtools genoemd in de checklist alleen kan worden bereikt door het naleven van schone code, het gebruik van moderne technologie, aandacht voor SEO on-page factoren etc. Anders zou de nieuwste webstandaarden en technische en SEO-eisen uiterst gedetailleerd in de productspecificatie moeten worden geformuleerd, waar klanten puur vakinhoudelijk niet toe in staat zijn. Als bureaus hoge waarden moeten behalen in de testtools, hebben ze geen andere keuze dan Best-Practice te werken – ook voor bureaus een nieuwe ervaring :-)

Het is tijd voor een bekentenis. Het formuleren van de SEO-eisen en de checklist-achtige aanpak met de verzekering en de verplichte behalen van doelwaarden in verschillende testtools vormt een ideaal dat in de werkelijkheid zelden te vinden is. Dit hangt af van:

• beperkingen van het budget van de klant
• winstoptimalisatiebelangen van het bureau
• beperkingen door de gebruikte technologieën
• en helaas ook: onwetendheid en incompetentie aan beide zijden

Ik kan de klant daar moeilijk de schuld van geven. Ze zoeken juist professionele hulp en bijna elk digitaal bureau vermeldt op hun website en in de whitepapers dat zoekmachineoptimalisatie een van hun kerncompetenties is. Er zijn altijd referenties die aantonen dat na de herlancering een toename van de online zichtbaarheid met een factor 3, 5 of 10 heeft plaatsgevonden. Dat van 10 bezoekers nu 100 per dag komen, is weliswaar een toename van 1000 procent, maar daarom nog lang geen succes. Veel zoekmachine successen zijn afhankelijk van het feit dat de concurrenten digitaal gewoon nog veel zwakker zijn.

Bureaus blijven middelmatig werk leveren met verouderde methoden, omdat ze tot op heden geen moderne tools voor kwaliteitsborging gebruiken, ook al wordt er grootschalig in posts, referenties, best practices etc. beweerd dat er SEO-expertise is. Misschien zijn dergelijke bureaus wel kennisgiganten, maar dan zijn ze ook uitvoeringsdwergen. Het klinkt hard, maar het is slechts de regel. Eerlijk waar. Bekijk het gerust eens nader! Neem de bovenstaande checklist en voer de beste bureau uit de regio waar je vandaan komt, met hun URL, in de genoemde tools in. En neem vervolgens de nieuwste website-referentie die je van het bureau vindt en herhaal het. Welke resultaten zul je zien? Precies die resultaten die je mag verwachten bij een samenwerking. Ook onze eigen referenties kun je op die manier controleren en je zult merken dat we zelfs bij onze klantprojecten niet altijd de topscores behalen. Zo'n workflow met de instelling van data-gedreven kwaliteitsborging is ook bij ons van project tot project gegroeid en heeft zich met name door onze werkzaamheden op TutKit.com gevestigd. 

Dergelijke controles kun je bij bijna elk bureau uitvoeren, omdat maar weinig bureaus echt data-gedreven werken op het gebied van kwaliteitsborging, omdat niemand met eigen projecten op de markt over meerdere jaren actief blijft en zich moet meten in de harde competitie om online zichtbaarheid met internationale spelers, en omdat het de bureaus bijna niets kan schelen of een project slaagt of niet, zolang de factuur van het bureau wordt betaald en de klanten de mooie (maar kwalitatief middelmatige) websites in hun posts en met awards kunnen vieren. De bijzondere ironie hierbij is dat juist de SEO-bureaus met hun eigen websites vaak het slechtst scoren in de bovengenoemde testtools, omdat ze vaak als een one-trick-pony slechts één methode in huis hebben ... een inhoudspakket voor de website dat is geoptimaliseerd voor de zoekwoorden van de klant. Voor de andere technische eisen ontbreken vaak gewoon de competente ontwikkelaars.

Een voordeel is dan ook wanneer het bureau zich elders bevindt en de klant niet tegenkomt tijdens het winkelen bij de bouwmarkt als verantwoordelijke bureaumedewerker die na een herlancering zorgt voor een zichtbaarheidsdaling in de dubbele cijfers. Maar deze zichtbaarheidsdaling controleren klanten hoe dan ook nauwelijks, omdat hoewel iedereen een cookie-toestemmingsbanner heeft, maar weinigen daadwerkelijk de cijfers evalueren en daar actiepunten uit halen. In geval van twijfel moet het advertentiebudget worden verhoogd. Gelukkig weten klanten vaak ook niet dat de organische ranking vandaag de dag vooral afhankelijk is van technische parameters, gebruikerssignalen en (nog steeds) backlinks vanwege het overaanbod van inhoudelijk vergelijkbare goed gepositioneerde websites, en door AI-teksttools zullen websites qua inhoud indrukwekkend verbeteren in zowel kwantiteit als kwaliteit en mogen we binnenkort vele nieuwe buitenlandse websites verwelkomen in onze landstaal op de zoekresultatenpagina's, omdat het steeds eenvoudiger wordt om online winkels, portals, SAAS en andere websites te vertalen en de digitale thuismarkt aan te vallen. We moeten ons voorbereiden op felle concurrentie. Het begint pas ...

Conclusie over de data-gedreven website-herlanceringscontrolelijst

Zo'n data-gedreven checklist is een van de weinige effectieve manieren om bureaus verplicht te stellen goed werk te leveren. Het is zelfs aan te raden om het behalen van bepaalde waarden in de testtools als acceptatiecriterium te maken. Contractueel moet worden vastgelegd dat een deel van het bedrag pas vier weken na de herlancering in rekening kan worden gebracht, als alle belangrijke gegevens beschikbaar zijn en het behalen van de topscores bevestigen (zoals bijvoorbeeld Core Web Vitals en de gevalideerde productsnippets volgens schema-markup in de Search Console). Met behulp van deze workflow - zoals beschreven in dit artikel - zal je zichtbaarheidsverlies na een herlancering met ingrijpende inhoudelijke, structurele en technische veranderingen beperkt blijven en leg je de basis voor Google om je website of online shop binnenkort hoger te rangschikken.

Als het artikel interessant voor je was, bekijk dan ook gerust meer inhoud van ons: