Contact

Voorkom rankverlies in 90 dagen met migratie naar HTTPS voor SEO

door | sep 9, 2026 | SEO | 0 Reacties

Serverinfrastructuur bij de overstap naar HTTPS

Migreer naar HTTPS. Niet volgende maand, niet “als het uitkomt”: nu. De vraag is niet of je moet migreren, maar of je het schoon doet. De allereerste actie die telt: een complete 301-redirectmap, één op één, zonder ketens, vóórdat je live gaat. Sla die stap over en je linkwaarde lekt weg als water uit een gebarsten emmer.

Kort samengevat:

  • Zorg dat alle oude HTTP-URL’s precies één 301-redirect naar de HTTPS-variant hebben, zonder ketens of tussenstappen, om linkwaarde te behouden.
  • Controleer en herstel actief mixed content door hardcoded HTTP-verwijzingen, CDN-instellingen en externe scripts te upgraden naar HTTPS voordat je live gaat.
  • Test of alle canonical tags, hreflang- en sitemap-URL’s correct naar HTTPS wijzen, en registreer de HTTPS-property apart in Search Console.
  • Monitor de site negentig dagen na livegang dagelijks op crawl- en indexeringsproblemen, en reageer direct op afwijkingen of lange crawlfrequentie.
  • Overweeg bij grote of complexe sites het inschakelen van een specialist, omdat verkeerde redirectketens wekenlang rankings kunnen schaden en moeilijk te herstellen zijn.
Nebber
Voorkom SEO-verlies bij HTTPS
Nebber helpt bedrijven met technische SEO en praktische adviezen om hun organische zichtbaarheid tijdens complexe migraties te verbeteren.

Inhoudsopgave

Wat is HTTPS-migratie en waarom is het geen keuze meer

HTTPS versleutelt het verkeer tussen browser en server. HTTP stuurt alles onversleuteld over de lijn, als een briefkaart die iedereen onderweg kan lezen. Dat verschil is niet cosmetisch. Moderne browsers waarschuwen bezoekers actief bij een onbeveiligde verbinding, en die waarschuwing kost je conversie voordat een bezoeker ook maar één woord van je pagina heeft gelezen.

Voor SEO is het verhaal net zo hard. HTTPS is de poort naar HTTP/2 en HTTP/3, de protocollen die pagina’s sneller laten laden door verbindingen efficiënter te bundelen. Zonder HTTPS speel je dus ook nog eens met een handicap op snelheid, en snelheid is een directe rankingfactor. De business case is dus tweeledig: vertrouwen bij de bezoeker, en toegang tot de snellere infrastructuur die Google beloont.

Maar een migratie is een operatie met risico, niet een vinkje dat je afvinkt. Verander je domeinstructuur zonder plan, dan verandert Google elke URL op je site tegelijkertijd van status. Dat is het moment waarop rankings kunnen kelderen: niet door HTTPS zelf, maar door de rommelige uitvoering ervan. De term “https migratie seo” duikt in elke zoekopdracht op omdat mensen precies dát scenario willen vermijden. Terecht.

Praktisch stappenplan: van pre-migratie tot 90 dagen na livegang

Een migratie zonder checklist is dweilen met de kraan open. Je repareert issues terwijl er drie nieuwe ontstaan. Hier is de volgorde die werkt, in de praktijk getest op tientallen sites.

Vóór livegang:

  1. Zet een volledige back-up en een staging-omgeving op die een exacte kopie is van productie.
  2. Crawl de hele site en maak een URL-inventaris; prioriteer pagina’s met verkeer, conversie of backlinks.
  3. Bouw de redirectmap: elke oude HTTP-URL krijgt precies één 301 naar zijn HTTPS-equivalent. Geen ketens, geen tussenstops.
  4. Installeer het certificaat en configureer de server voor TLS, HTTP/2 en HTTP/3.
  5. Werk canonical tags, XML-sitemap, hreflang en interne links bij naar HTTPS.
  6. Test de hele staging-omgeving op mixed content en herstel wat je vindt.

Bij en na livegang:

  • Dien de nieuwe sitemap in bij Google Search Console en registreer de HTTPS-property apart.
  • Controleer serverlogs op Googlebot-verzoeken naar de nieuwe URL’s.
  • Start een monitoringperiode van 90 dagen met vaste criteria voor wanneer je ingrijpt of terugdraait.

Elke stap hierboven lijkt eenvoudig op papier. In de praktijk struikelen negen van de tien migraties over stap 3: de redirectmap. Mensen laten een plugin of server-rule “automatisch” alles afhandelen, en die automatiek gooit er vaak 302’s tussen of laat ketens ontstaan van drie stappen. Elke extra stap in een redirectketen verdunt linkwaarde en vertraagt de crawler, dus die “makkelijke” oplossing is precies de oorzaak van het rankverlies waar je bang voor was.

Pro-tip: Test je redirectmap eerst op tien representatieve top-URL’s uit je verkeerslijst. Zit er ergens een keten of een 302 in die steekproef, dan is de kans groot dat je hele redirect-logica systemisch fout zit. Fix het patroon, niet de losse URL.

Rollback-criteria horen ook in deze fase vastgelegd, niet pas als de paniek toeslaat. Spreek van tevoren af: bij welk percentage verkeersverlies na welk aantal dagen trek je de noodrem? Zonder die afspraak besluit je onder druk, en beslissingen onder druk zijn zelden de beste.

Praktisch stappenplan: van pre-migratie tot 90 dagen na livegang — overview diagram

Hoe bereid je de migratie voor: crawl, redirects en externe afhankelijkheden

Voordat er ook maar één certificaat wordt geïnstalleerd, moet je weten wat er ligt. Dit is het inventarisatiewerk dat niemand leuk vindt en dat toch het verschil maakt tussen een soepele overstap en een maandenlange opruimactie.

Crawl de volledige site met een tool die statuscodes, canonicals en redirects in kaart brengt. Exporteer elke HTTP-URL die bestaat, inclusief pagina’s die je zelf vergeten was. Sites die tien jaar meegaan, verzamelen duizenden vergeten landingspagina’s, oude campagne-URL’s en testpagina’s die nooit offline gingen. Elke URL die je mist in de redirectmap wordt straks een dode link of, erger, een pagina die zowel op HTTP als HTTPS bereikbaar blijft.

Rangschik daarna op prioriteit. Niet elke URL is evenveel waard.

Prioriteitsniveau Kenmerk Actie
Hoog Top-landingspagina’s met organisch verkeer of externe backlinks Eerst controleren, handmatig valideren na livegang
Middel Productpagina’s en categoriepagina’s zonder piekverkeer Automatisch meenemen in de standaard redirectmap
Laag Verweesde of verlaten testpagina’s zonder verkeer Overwegen te laten vervallen in plaats van redirecten

Naast de eigen URL’s moet je de externe afhankelijkheden in kaart brengen: widgets van derden, embedded video’s, advertentiescripts en CDN-verwijzingen. Elk van die onderdelen moet zelf ook over HTTPS beschikbaar zijn, anders importeer je straks je eigen mixed content probleem via een extern script dat je niet zelf beheert.

Sluit deze fase af met een rollback-plan en testcases voor de staging-omgeving. Schrijf op papier wat “geslaagd” betekent voor elke testcase: welke pagina’s moeten laden, welke headers moeten aanwezig zijn, welke redirects moeten in exact één stap gaan. Zonder die criteria test je in het wilde weg en mis je precies de fout die je later duur komt te staan.

Bekijk ook de achtergrond over wat HTTPS voor SEO betekent als je nog twijfelt over de volgorde van deze voorbereiding.

Hoe implementeer je certificaat, redirects, HSTS en CSP correct

Dit is het technische hart van de operatie, en hier gaat het meeste mis omdat mensen de volgorde omdraaien.

Begin met het certificaat. Kies een certificaatketen die de volledige chain bevat (fullchain), niet alleen het eindcertificaat: browsers moeten de hele vertrouwensketen kunnen valideren, anders krijgen sommige bezoekers toch een waarschuwing. Valideer na installatie met een externe TLS-checker of de configuratie correct is en of verouderde protocollen zoals TLS 1.0 en 1.1 zijn uitgeschakeld.

Vervolgens de redirects. Elke 301 moet in één stap gaan van de oude HTTP-URL naar de definitieve HTTPS-URL. Geen tussenlanding op een andere HTTP-pagina, geen 302 die “tijdelijk” bedoeld is en jarenlang blijft staan. Redirectketens verdunnen linkwaarde en vertragen crawls, en dat is precies het lek waar je linkwaarde doorheen wegstroomt zonder dat je het merkt.

Daarna, en niet eerder, komt HSTS aan de beurt. HSTS dwingt browsers om altijd HTTPS te gebruiken voor je domein, zelfs als iemand per ongeluk het HTTP-adres intikt. Preload-submission, waarbij je domein permanent in de browserlijst wordt opgenomen, doe je alleen na grondige controle: HSTS is als het slot op de deur zetten voordat je zeker weet dat iedereen binnen is — zet het te vroeg vast en je sluit bezoekers buiten die nog ergens op HTTP terechtkomen. Terugdraaien is lastig omdat de instelling client-side wordt opgeslagen in de browser van de bezoeker.

Als tijdelijk vangnet, terwijl je nog her en der hardcoded http:// verwijzingen aan het opruimen bent, zet je de header Content-Security-Policy: upgrade-insecure-requests in. Die header upgrade’t onveilige interne verzoeken automatisch naar HTTPS, zonder dat je elke losse link met de hand moet vinden. Zie het als een noodpomp: hij houdt het droog terwijl de loodgieter het echte lek repareert, maar hij is geen vervanging voor die reparatie.

Vergeet ten slotte niet de onderdelen die buiten de directe HTML-content liggen:

  • Structured data (schema.org-markup) moet ook HTTPS-URL’s bevatten, anders klopt de data niet met de daadwerkelijke pagina.
  • Canonical tags moeten zonder uitzondering naar de HTTPS-versie wijzen.
  • robots.txt en de sitemap-referentie daarin moeten naar het HTTPS-domein verwijzen.

Pro-tip: Zet een monitoringmelding op je certificaat-vervaldatum minstens dertig dagen van tevoren. Een verlopen certificaat is een van de weinige fouten die een volledig gemigreerde, goed presterende site binnen een uur naar nul kan brengen.

Pagina’s met waarschuwingen door onveilige content laden gemiddeld 23% minder vaak gecrawld dan schone HTTPS-pagina’s, en zien vaak ook een verslechtering in de laadprestatie die Core Web Vitals meet. Dat cijfer alleen al is genoeg reden om de implementatiefase niet af te raffelen.

Hoe spoor je mixed content op en los je het op

Mixed content betekent dat een HTTPS-pagina nog steeds onderdelen ophaalt via het onveilige HTTP-protocol. Er zijn twee soorten, en het onderscheid bepaalt je urgentie.

Passieve mixed content betreft bijvoorbeeld afbeeldingen die nog via HTTP laden. Vervelend, maar de browser toont vaak alleen een waarschuwing. Actieve mixed content is een ander verhaal: scripts, stylesheets en iframes die via HTTP binnenkomen worden door browsers actief geblokkeerd, en die blokkade breekt in het slechtste geval de hele weergave van je pagina. Sinds Chrome 134 zijn browsers hierin nóg strenger geworden. Actieve mixed content krijgt daarom altijd voorrang bij het repareren.

Zo pak je het aan, stap voor stap:

  1. Crawl de volledige live-site met een tool als Screaming Frog of ScreamingCat, specifiek gericht op mixed content detectie. De browserconsole vangt slechts een fractie van de issues omdat je die alleen op pagina’s ziet die je zelf handmatig bezoekt.
  2. Open de DevTools van je browser op steekproefpagina’s om de gevonden meldingen te bevestigen en de exacte bron te lokaliseren.
  3. Fix hardcoded links in de database. Bij WordPress-sites is een search-replace via WP-CLI de snelste route: dit lost vaak 60 tot 80% van alle mixed content issues in één keer op, altijd met een verse back-up en de skip-guides flag om binaire data niet te beschadigen.
  4. Controleer thema-bestanden en templates op hardcoded http:// verwijzingen die niet in de database staan.
  5. Check CDN-instellingen en iframe-embeds van externe partijen; die vallen buiten je eigen database en moeten los worden aangepast of vervangen.
  6. Her-crawl de volledige site om te bevestigen dat de meldingen verdwenen zijn.

Laat de upgrade-insecure-requests header intussen aanstaan als vangnet, maar behandel hem niet als eindstation. Die header lost het symptoom op, niet de wortel. Wortel eruit, altijd.

Pro-tip: Bewaar een lijst van elke gevonden mixed content bron met datum en oplossing. Bij de volgende grote contentupdate duikt vaak precies hetzelfde patroon weer op, en dan wil je die lijst als naslag hebben.

Welke tests moet je uitvoeren voordat de migratie geslaagd is

Een migratie is niet geslaagd omdat de site “het doet”. Hij is geslaagd omdat een reeks harde criteria klopt, op staging en daarna op live.

Crawl beide omgevingen volledig en controleer elke responscode. Elke oude URL moet een directe 301 geven, zonder tussenstations. Loop vervolgens de kritieke elementen na:

  • Canonicals wijzen zonder uitzondering naar de HTTPS-versie van elke pagina.
  • Hreflang-tags verwijzen naar HTTPS-varianten, niet naar de oude HTTP-URL’s van andere taalversies.
  • De sitemap bevat alleen HTTPS-URL’s en is opnieuw ingediend bij Search Console.
  • Structured data verwijst intern naar HTTPS-adressen, consistent met de canonical.

Gebruik de URL-inspectietool in Search Console om te controleren of Google de nieuwe versie al als canonieke bron herkent. Vergeet ook niet de Search Console property voor het HTTPS-domein apart te registreren: zonder die stap meet je straks half op de oude, half op de nieuwe property, en klopt geen enkel rapport meer. Analytics-tracking verdient dezelfde controle.

Serverlogs geven je het eerlijkste beeld. Filter op Googlebot-verzoeken en kijk of de crawler daadwerkelijk de nieuwe HTTPS-URL’s oppakt in plaats van vast te blijven hangen op de oude structuur.

Sluit af met een snelheidstest en een Core Web Vitals check, vóór en na de livegang, op dezelfde representatieve pagina’s. Een migratie die technisch klopt maar de laadtijd verslechtert, wint de wedstrijd op papier en verliest hem in de praktijk. Voor extra achtergrond over het herkennen van indexeringsproblemen na een wijziging als deze is de gids over indexeringsfouten in Search Console een goed vervolg.

Hoe monitor je de eerste 90 dagen na de livegang

De eerste week bepaalt of je een probleem vroeg genoeg vindt om het klein te houden, of laat genoeg om het groot te laten worden.

  1. Dag 0 tot 7: controleer dagelijks de indexatiestatus in Search Console, scan op redirect-fouten in de serverlogs en houd je top-landingspagina’s persoonlijk in de gaten. Dit is de fase waarin je elke afwijking direct oppakt, niet aan het einde van de week verzamelt.
  2. Week 2 tot 4: vergelijk verkeer en posities met je baseline van vóór de migratie. Analyseer serverlogs op crawlfrequentie: een dalende trend hier is vaak de eerste waarschuwing, weken voordat het in je rankings zichtbaar wordt.
  3. Doorlopend, wekelijks: check Core Web Vitals en let op onverklaarbare schommelingen in klikfrequentie (CTR) in de zoekresultaten. Een dalende CTR bij gelijke posities wijst vaak op een technisch probleem met de weergave, niet op interesse van de zoeker.

Pagina’s met resterende mixed content vertonen gemiddeld 23% minder crawlfrequentie, en die crawlvertraging is meestal het eerste meetbare signaal dat er ergens nog een lek zit voordat het in de rankings zichtbaar wordt. Wacht niet tot de ranking daalt: reageer op het crawlsignaal.

Een uitgebreider stappenplan voor deze fase, inclusief templates voor het dagelijkse dashboard, staat in de gids over SEO-migratiestappen en 90 dagen monitoring.

Zo pakt Ramon een HTTPS-migratie aan

Negentien jaar SEO leert je één ding vooral: technische migraties gaan zelden mis op het grote plan. Ze gaan mis in de details die niemand had opgeschreven. Mijn aanpak volgt daarom altijd drie fasen: audit, implementatie en negentig dagen monitoring, in die volgorde en nooit gemixt.

De audit brengt elke URL, elke redirect en elke externe afhankelijkheid in kaart voordat er iets verandert. De implementatiefase voert de redirectmap uit, fixt mixed content en configureert certificaat en headers. De monitoringfase, negentig dagen lang, vangt precies de afwijkingen die anders onopgemerkt blijven totdat het te laat is.

Concreet leveren die drie fasen:

  • Een complete redirectmap met elke oude URL gekoppeld aan zijn definitieve HTTPS-bestemming.
  • Een crawlrapport met statuscodes, canonicals en gevonden mixed content per pagina.
  • Een lijst met uitgevoerde fixes, inclusief prioritering op verkeer en backlinkwaarde.
  • Een dashboard voor de negentig dagen monitoring met dagelijkse en wekelijkse metingen.

Wie meer wil lezen over de technische basis achter dit proces vindt achtergrond in de gids over CMS-beperkingen die SEO schaden, vaak de verborgen oorzaak van mixed content die niet in een standaard crawl opvalt.

Zelf doen of een specialist inschakelen?

Kleine sites zonder legacy content, zonder honderden oude campagnepagina’s, kun je zelf migreren met de checklist hierboven. De risico’s zijn beheersbaar en de foutmarge is klein.

Grote sites met duizenden URL’s, jarenlange backlinkopbouw of een complexe CDN-configuratie zijn een ander verhaal. Daar wint een verkeerde redirectketen niet zomaar een paar posities, maar kan het weken aan herstel kosten. Die oorlog win je niet met een paar interne links en goede bedoelingen.

De praktische drempel is meestal niet kennis, maar tijd en rollback-capaciteit: heb je de mensen om binnen 24 uur een fout terug te draaien? Zo niet, dan is het inschakelen van een specialist geen luxe maar risicomanagement.

— Ramon

Wat Nebber doet bij een HTTPS-migratie

Nebber is de praktische keuze voor wie een migratie zonder gedoe wil, in plaats van weken zelf uit te zoeken waarom de rankings schommelen. Ik lever de audit, de complete redirectmap, de mixed content fixes en daarna negentig dagen monitoring met vaste rollback-criteria, zodat je niet zelf elke dag serverlogs hoeft te lezen.

Nebber

Dat is precies waar de meeste migraties misgaan: niet bij het certificaat, maar bij het gebrek aan iemand die de negentig dagen ná livegang serieus bijhoudt. Heb je een grote site, veel backlinks of een CMS dat al jaren meegaat zonder opschoning? Vraag een gratis quick-scan aan via Nebber en je weet binnen een paar dagen waar de risico’s precies zitten, voordat je zelf tegen een dalende ranking aanloopt.

Voor de serverkant van de operatie, denk aan hosting of een technische herbouw, is een partner als Sneleenwebsitenodig een goed startpunt als je eerst je infrastructuur op orde wilt hebben.

Bronnen

Aanbevelingen