Website migratie: de meestverkomende SEO problemen

Een websitemigratie is vaak nodig wanneer de site een grote verandering doormaakt. Soms moet een site verhuizen naar een ander CMS, of moet de url structuur gewijzigd worden. Zo’n sitemigratie verloopt het liefst vlekkeloos. Maar vaker, dan niet, komen er problemen voor die je liever niet had gehad. Ik heb door de jaren heen een aantal migraties mogen leiden en begeleiden, waardoor ik altijd wel een aantal problemen zie terugkomen. Die SEO gevaren heb ik in de lijst hieronder verzameld, zodat jij ze allemaal kunt voorkomen. 😉

1) Migreren in of net voor het hoofdseizoen

Migreren voordat jouw belangrijkste periode van het jaar begint? Liever niet. Probeer een migratie altijd na het hoofdseizoen te doen. Dit lijkt een heel logische aanname, maar vaak lopen ideeën uit de hand, of loopt de migratie vertraging op. Ook wanneer je in de originele planning hoogstwaarschijnlijk in het laagseizoen wou migreren, komt het voor dat je door allerlei redenen dat opeens in het hoogseizoen moet doen. Wat nu?

Ai. En dat is juist wat je wilt voorkomen. Migreren in een hoogseizoen betekent meer kans op verlies. Verlies in verkeer, maar ook verlies in omzet. 😉

Oplossing?

Begin zo vroeg mogelijk met de voorbereiding. Begin nu alvast met het maken van een planning, en richt een migratie-team op met de verschillende specialisaties. Check welke content componenten je nodig hebt, en welke nog gemaakt moeten worden.

Want liever begin je te vroeg, dan te laat. Er zal voor een bepaald onderdeel altijd uitloop ontstaan, waardoor de deadline in gevaar komt. Tel bij de originele planning dus ook altijd een aantal maanden extra speling op.

2) Alles een make-over willen geven

Vaak wordt gedacht dat een migratie een nieuwe start is. En bij die nieuwe start hoort dan toch een nieuwe homepagina? Nee. Een nieuwe navigatie dan? Ook niet. Kan ik de content dan wel aanpassen? Nee.

Een website migratie moet je eerder zien als een grote opruiming, dan een punt waarop je de hele website kunt vernieuwen. 🙂 En natuurlijk zou je onder het mom rebranding een totaal nieuwe website kunnen creëren, voor SEO is dat niet echt gewenst.

Het hele probleem met die last-minute aanpassingen, is dat het de hele dynamiek van een site of een pagina kan veranderen. En, als de migratie dan helemaal misgaat, hoe weet je dan wat de oorzaak is? Als pagina X opeens in de rankings gedaald is, ligt dat dan aan de nieuwe copy, aan de nieuwe indeling van de navigatie, of aan een fout bij de migratie?

Oplossing?

Voor de migratie is er waarschijnlijk veel tijd binnen de teams gecreëerd, waardoor je geneigd bent van alles op te pakken. Normaal is die tijd er niet. Gebruik die tijd daarom om onderzoek te doen, ideeën uit werken en de ROI te berekenen.

Maar, en hier komt de clue, wacht met de uitvoering ervan tot een aantal maanden na de migratie. Het fijne van die uitwerking is dat je een gegronde basis hebt voor het plaatsen van dat project op een sprint of jaarplanning.

3) Waarom is een afbeelding van 30 MB nodig?

Afbeeldingen worden vaak door meerdere personen in het CMS geplaatst. Dit doen content managers, marketeers, designers of stagiaires. Als leek gooi je dan wat afbeeldingen online. En als je een deadline moet halen ga je ook niet al die afbeeldingen optimaliseren, toch?

Fout. Zo ontstaat er bij livegang opeens een afbeeldingen reeks van 1MB, 5 MB, maar ook plaatjes van 30 MB ben ik wel eens tegengekomen.

Oplossing:

• Deel je kennis met je collega’s – wat ze niet weten, kunnen ze niet voorkomen.
• Pak het probleem bij de bron aan, en stel in samenwerking met development een maximum aantal kb in voor het uploaden van de afbeeldingen in het CMS.
• Bij een SEO quickscan kun je de afbeeldingen sorteren op aantal bytes. Dan zie je vanzelf of er grote uitschieters zijn, of niet.

4) Mensjes, praat nu eens met elkaar

Bij het migreren van een website moeten er een heleboel beslissingen worden genomen. Niet alles kan, is mogelijk of gewenst. Verschillende stakeholders hebben een mening over de website. Wat helemaal prima is. maar die meningen botsen wel eens.

In veel gevallen is er een middenweg te vinden, maar dan moet de ander wel van het probleem afweten. Soms komt dat probleem niet altijd bij de juiste personen terecht, of worden de juiste personen niet op tijd aangehaakt.

Oplossing:

Voorkomen is beter dan genezen. Maak het jezelf dus gemakkelijke en richt een migratie-team op. Dat team bestaat uit een aantal belangrijke rollen: bijvoorbeeld de product-owner van het project, een analist, een ux-specialist, een seo specialist en een developer.

Het is belangrijk dat deze groep niet te groot wordt, maar wel alle collega’s bevat die een cruciale of sturende rol bij de migratie hebben. Met dat team ga je wekelijks, om de twee weken of elke maand samenzitten om te bespreken wat er speelt, welke dingen goed en mis gaan, en wat er nog geregeld moet worden.

5) Live gaan op no-index

De grootste fout die je kunt maken bij een livegang van een website, is live gaan met een noindex/nofollow. Met als gevolg dat als Google je website weer bezoekt, de pagina’s uit de index haalt, en niet meer zichtbaar is in de SERP, en dus ook niet meer te bezoeken is door organische bezoekers.

En dat is een worst-case scenario. Geen indexatie en geen organisch verkeer, betekent ook geen organische omzet.

Oplossing?

Check een aantal technische punten vlak voor livegang. Maak ruim van te voren een checklist met welke zaken je moet wijzigen bij livegang. Zo kan een indexatieprobleem voorkomen worden. Maar als dit probleem alsnog ontstaat, moet het opvallen wanneer je een SEO technische quickscan doet, vlak na livegang.

Dit houdt in dat je de nieuwe website op een aantal cruciale punten checkt. Denk hierbij aan de index-tag, canoncial-tag, de crawlbaarheid van de website, het robots-bestand, enzovoort. Doe die quickscan meteen na livegang om mogelijke schade te beperken.

6) Staging-urls in de sitemap

Dit is niet het grootste probleem bij een migratie, maar raar genoeg komt dit toch vaak terug. Een sitemap begeleidt Google naar de juiste pagina’s. Zie het als een soort gids die je vrijblijvend rond probeert te leiden. En dan is het vrij vervelend als je op urls uitkomt die niet bestaan of niet toegankelijk zijn voor het publiek.

Oplossing?

Ook hier is de SEO technische quickscan belangrijk. Dit punt kan daarom makkelijk ontdekt en opgelost worden. Een sitemap is vaak zo gemaakt, en omdat de een sitemap een guideline is en geen harde eis, hoeft dit echt niet meteen als een prio 1 opgelost te worden als er belangrijkere technische problemen zijn.

7) Veel te veel (overbodige) redirects

Een grote website heeft veel pagina’s en afbeeldingen. Maar soms is een website zo verwaarloost door de jaren heen, dat er een heleboel pagina’s en bestanden verwijderd kunnen worden. Dan ontstaat er soms een situatie waarbij het lijkt alsof je alle bijvoorbeeld 10.000 urls moet redirecten. De redirect tool van het CMS wordt dan soms overspoeld door duizenden overbodige redirects, waardoor de tool onwerkbaar wordt. De kans op redirect chains is hierdoor ook een stuk groter.

Oplossing:

Bij pagina’s zonder backlinks en erg weinig visits is een redirect vaak niet nodig. Met die twee metrics kun je de hele lijst van urls sorteren en bepalen wat ermee moet gebeuren. Het voordeel van zo’n diepere analyse is dat de redirect tool overzichtelijk en bewerkbaar blijft voor de content managers.

Ga hier wel met zorg mee om. Backlinks en het redirecten van SEO waarde is een onmisbaar element in de hele migratie. Wanneer je hier niet zorgvuldig mee om gaat, bestaat de kans dat je rankings en relevant verkeer verliest.

8) Verkeerde canonical url

Hop, de website is live, het SSL certificaat lijkt te werken, dus het zal wel goed gaan. Alleen jammer dat de zelf-refererende canonieke url dan niet naar de beveiligde url verwijst: de HTTP-variant wordt gebruikt op alle pagina’s. Dat is niet hoe je een livegang wil beginnen, want zo’n fout kan makkelijk voorkomen worden. Ook typfouten of verwijzen naar een url die niet bestaat komt wel eens voor. Maar de HTTP-verwijzing zie ik toch wel het meest voorbijkomen.

Het grote SEO probleem aan een geredirecte of niet-bestaande url te gebruiken als canonieke url is dat de zoekmachines de pagina misschien niet zal indexeren. Je zegt immers dat een andere pagina (die niet bestaat, hetzij 404 of een redirect chain) de betere versie is. Dat is niet alleen voor jezelf, maar ook voor Google verwarrend.

Oplossing:

• Zorg ervoor dat de URL in rel=canonical de juiste URL is van de canonieke pagina;
• Dubbelcheck of je http of https moet gebruiken;
• Doe vlak na livegang een SEO quickscan en dubbelcheck of de juiste canonical urls zijn gebruikt.