Waarom www. en Apex-domeinen moeten worden samengevoegd (Het belang van 301/308 redirects)

Heeft u de laatste tijd goed gekeken naar moderne browsers zoals Chrome, Edge of Safari? Als u www.naver.com of www.google.com in de adresbalk typt, zult u merken dat de www op een gegeven moment verdwijnt en alleen het hoofddomein (Apex Domain) overblijft. Zelfs m.-domeinen voor mobiel worden vaak verborgen.

Dit komt door het beleid van moderne browsers om 'triviale subdomeinen' te verbergen, om zo de adresbalk visueel op te schonen. Voor gebruikers kan een korter adres prettiger zijn, maar als webontwikkelaar moet u een stap verder denken. Er is namelijk een groot verschil tussen 'wat de browser verbergt' en 'wat daadwerkelijk als een apart domein functioneert'.

Stroomschema ter vergelijking voor en na het toepassen van redirects

DNS en zoekmachines zien 'www' wel degelijk

Voor het daadwerkelijke DNS-proces en voor zoekmachine-robots (zoals Googlebot) zijn www.example.com en example.com duidelijk verschillende bestemmingen. Als beide adressen een 200 OK-antwoord retourneren en dezelfde inhoud tonen, komt dit technisch gezien neer op twee websites die met 'dubbele inhoud' opereren.

Laten we met het curl-commando direct controleren hoe grote IT-bedrijven dit probleem aanpakken.

1. Het geval van Yahoo Japan

$ curl -I https://yahoo.co.jp/
HTTP/2 301 
location: https://www.yahoo.co.jp:443/
...

Yahoo Japan stuurt, wanneer u via het Apex-domein verbinding maakt, een 301 Moved Permanently redirect naar het adres met www.

2. Het geval van Google

$ curl -I https://google.com/
HTTP/2 301 
location: https://www.google.com/
...

$ curl -I https://www.google.com/
HTTP/2 200 
...

Google doet hetzelfde. Als u google.com bezoekt, wordt u doorgestuurd naar www.google.com, waarna uiteindelijk alleen het www-domein een 200-antwoord retourneert.

Waarom is het essentieel om naar één variant te redirecten?

Het gaat niet alleen om een 'nettere' weergave. Er zijn duidelijke redenen op het gebied van SEO (zoekmachineoptimalisatie) en operationele efficiëntie.

1. De beperkingen van de Canonical Tag

Veel ontwikkelaars denken dat het volstaat om de <link rel="canonical" href="..."> tag in te stellen. Echter, een canonical tag is slechts een 'hint' voor zoekmachines. Het feit dat robots beide URL's moeten crawlen, verandert niet, en dit leidt tot verspilling van het crawlbudget. De robot besteedt dan tijd aan het crawlen van 'kopieën' van bestaande artikelen, in plaats van nieuwe inhoud op uw site te indexeren.

2. Versnippering van Link Juice

Wanneer andere websites op het web naar uw artikel linken, zal de één www toevoegen en de ander niet. Zonder correcte redirecting wordt de autoriteit die een pagina zou moeten opbouwen, verspreid over twee domeinen, wat u benadeelt in de concurrentie om zoekmachinerankings.

De oplossing: Geforceerde redirect op webserverniveau

Deze afhandeling is het meest efficiënt op het niveau van de webserver (infrastructuur), zoals Nginx of Apache, en niet op het niveau van de applicatiecode (zoals Django, Node.js, etc.). Door de aanvraag onmiddellijk om te leiden voordat deze de applicatie bereikt, wordt er minder bronnen verbruikt en is de snelheid hoger.

Hieronder vindt u een voorbeeld van een Nginx-configuratie om alle verzoeken te uniformeren naar het Apex-domein (https://example.com) wanneer u example.com beheert. (Als u daarentegen wilt uniformeren naar www, hoeft u alleen het doeladres aan te passen.)

# 1. www (HTTP) -> Apex (HTTPS)
server {
    listen 80;
    listen [::]:80;
    server_name www.example.com;
    return 308 https://example.com$request_uri;
}

# 2. www (HTTPS) -> Apex (HTTPS)
server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name www.example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    return 308 https://example.com$request_uri;
}

# 3. Apex (HTTP) -> Apex (HTTPS)
server {
    listen 80;
    listen [::]:80;
    server_name example.com;
    return 308 https://example.com$request_uri;
}

# 4. Werkelijke servicelogica (Apex HTTPS 200 OK)
server {
    listen 443 ssl http2;
    server_name example.com;
    # ... serviceconfiguratie en Proxy Pass etc.
}

Tip: De reden waarom hier de 308-statuscode in plaats van 301 wordt gebruikt, is dat 308 Permanent Redirect de HTTP-methode (POST, PUT, etc.) ongewijzigd laat en deze behoudt bij het doorsturen, wat veiliger is in de moderne webomgeving.

Tot slot

Al verbergt de browser de URL, dit betekent niet dat de server passief mag blijven. Als www- en Apex-domeinen naast elkaar bestaan en beide een 200-status retourneren, controleer dan onmiddellijk uw webserverinstellingen. Een duidelijke redirect naar één variant is de meest fundamentele en belangrijke stap om de identiteit van uw site duidelijk te maken aan zoekmachines.