# 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](/media/whitedec/blog_img/77ecb43d3845413385e9e0ebf6cc351f.webp)


## DNS en zoekmachines zien 'www' wel degelijk {#sec-e0d49c76d3ea}

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**
```bash
$ 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**
```bash
$ 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? {#sec-cf467e61a55d}

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 {#sec-9531d19b126b}
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 {#sec-c445aae506c3}
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 {#sec-e499a7960796}

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.)

```nginx
# 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 {#sec-ad06e7ff5f93}

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.