301-redirects in .htaccess tijdens een domeinmigratie

Wie zoekt op .htaccess 301 redirect heeft meestal een heel concreet probleem:

• een oude URL moet naar een nieuwe
• HTTP moet naar HTTPS
• een oud domein moet permanent verhuizen

Voor een paar regels kan .htaccess prima volstaan. Het probleem begint wanneer die aanpak wordt opgerekt tot een volledige domeinmigratie.

De praktische conclusie is meestal:

• voor een klein aantal stabiele 301-redirects kan .htaccess genoeg zijn
• voor rebrands, relaunches, domeinmigraties of grote redirect maps wordt .htaccess snel een bron van operationeel risico

Als je migratie al loopt, houd dan ook de website migration redirect checklist erbij. Dit artikel zoomt in op het klassieke startpunt: 301-redirects in .htaccess.

Het korte antwoord

Een eenvoudige regel kan er zo uitzien:

Redirect 301 /oude-pagina https://www.voorbeeld.nl/nieuwe-pagina

En een complete domeinverhuizing met behoud van path eindigt vaak in mod_rewrite:

RewriteEngine On
 
RewriteCond %{HTTP_HOST} ^oud-domein\.nl$ [OR]
RewriteCond %{HTTP_HOST} ^www\.oud-domein\.nl$
RewriteRule ^(.*)$ https://www.nieuw-domein.nl/$1 [R=301,L]

Dat beantwoordt de syntaxis. De echte vraag is:

[!TIP] Beheer je nog een paar redirects, of beheer je inmiddels een migratieworkflow die validatie, ownership en rollback nodig heeft?

Wanneer .htaccess nog prima werkt

Dat is meestal wanneer:

• het aantal redirects klein is
• Apache echt de enige actieve laag is
• geen CDN, proxy of middleware ook routes herschrijft
• path-logica eenvoudig blijft
• ownership duidelijk is

Waar het mis begint te gaan

1. Er zijn meerdere redirectlagen actief

In echte stacks komen redirects vaak uit:

• .htaccess
• CMS-plugins
• Nginx of load balancers
• Cloudflare
• app-middleware

Dan wordt een simpele verhuizing al snel:

http://oud-domein.nl/product-a
  -> https://oud-domein.nl/product-a
  -> https://www.oud-domein.nl/product-a
  -> https://www.nieuw-domein.nl/shop/product-a

Dat kan nog werken, maar het is nog steeds een slechte migratie-uitkomst.

2. Path en query worden onduidelijk

Veel teams testen alleen de homepage. Later blijkt dat deep links, docs of UTM’s niet goed uitkomen.

3. Wildcards zijn niet altijd genoeg

Een regel als:

/blog/* -> /artikelen/*

lijkt strak, totdat:

• categorieën zijn samengevoegd
• producten zijn verdwenen
• uitzonderingen nodig zijn

Dan heb je nodig:

• expliciete mappings
• prioriteiten
• validatie
• een redirect map die te reviewen is

4. Wijzigingen zijn lastig te auditen

Een merge in een configbestand is geen migratie-audit.

Al snel wil het team weten:

• wie wat wijzigde
• welke regels nieuw zijn
• welke weg zijn
• waar conflicten zitten
• hoe rollback werkt

.htaccess alleen geeft daar weinig grip op.

Veelgemaakte fouten

Host, HTTPS en eindbestemming in meerdere hops verdelen

Slecht:

http://oud-domein.nl/docs/api
  -> https://oud-domein.nl/docs/api
  -> https://www.oud-domein.nl/docs/api
  -> https://www.nieuw-domein.nl/docs/api

Beter:

http://oud-domein.nl/docs/api
  -> https://www.nieuw-domein.nl/docs/api

De homepage testen en de belangrijke URL’s vergeten

De home lijkt goed, maar producten, artikelen, docs en oude organische URL’s doen iets anders.

Parameters verliezen

Als tracking afhangt van e-mail, QR, paid social of partnerlinks, maken verdwenen utm_-waarden van de migratie meteen ook een reportingprobleem.

De redirect map buiten de live laag laten leven

Als de waarheid in een spreadsheet staat en de live regels in serverconfig, ontstaan blinde vlekken.

Wanneer je van workflow moet wisselen

Dat punt is meestal bereikt wanneer:

• je honderden of duizenden URL’s migreert
• meerdere teams of bureaus regels wijzigen
• je CSV-import nodig hebt
• conflicten vóór go-live gevalideerd moeten worden
• rollback helder moet zijn
• je niet steeds origin wilt deployen voor kleine redirectwijzigingen

Dan wordt UrlEdge relevant:

• bulk URL management voor grote redirect maps
• redirect management voor ownership en rollout
• permanent 301 redirects voor duurzame migraties

Conclusie

De echte vraag is niet of .htaccess goed of slecht is.

De echte vraag is:

Past je migratie nog in een paar handmatige serverregels, of draai je inmiddels een routingproject met SEO-, campagne- en teamafhankelijkheden?

Als dat laatste waar is, dan is een snippet niet meer de hele oplossing.