Hoe u HTTP omleidt naar HTTPS in WordPress

Het verplaatsen van uw WordPress-site van HTTP naar HTTPS is niet langer optioneel. Browsers markeren HTTP-sites als "Niet beveiligd," Google gebruikt HTTPS als rankingsignaal, en de gegevens van uw bezoekers worden zonder versleuteling in platte tekst verzonden. Na het installeren van een SSL-certificaat moet u al het HTTP-verkeer correct omleiden naar HTTPS en eventuele resterende mixed-contentproblemen oplossen. Deze handleiding behandelt elke stap van het proces, van het verkrijgen van een certificaat tot het debuggen van redirect loops achter load balancers.

Waarom HTTPS belangrijk is naast basisbeveiliging

De voor de hand liggende reden voor HTTPS is versleuteling. Zonder dit kan alles tussen de browser van uw bezoeker en uw server (formulierinzendingen, inloggegevens, cookies, persoonsgegevens) worden onderschept door iedereen op hetzelfde netwerk. Maar HTTPS is om verschillende andere redenen belangrijk die direct van invloed zijn op het succes van uw site:

• SEO-rankingfactor: Google bevestigde in augustus 2014 dat HTTPS een rankingsignaal is. Hoewel het een lichtgewicht signaal is, zal de HTTPS-versie van een pagina, alle andere zaken gelijk, hoger ranken dan de HTTP-versie. In competitieve niches telt elk signaal.
• Browserwaarschuwingen: Chrome, Firefox, Safari en Edge tonen allemaal "Niet beveiligd"-waarschuwingen voor HTTP-pagina's, vooral die met formulierinvoer. Dit ondermijnt het vertrouwen van bezoekers en verhoogt het bouncepercentage. Chrome maakt deze waarschuwingen sinds Chrome 68 (juli 2018) steeds prominenter.
• HTTP/2- en HTTP/3-ondersteuning: Moderne protocollen zoals HTTP/2 en HTTP/3, die de paginalaadsnelheid drastisch verbeteren door multiplexing en header-compressie, vereisen in de praktijk HTTPS. Alle grote browsers ondersteunen HTTP/2 alleen via TLS.
• Referrer-gegevens: Wanneer een bezoeker op een link klikt vanaf een HTTPS-pagina naar een HTTP-pagina, verwijdert de browser de referrer-koptekst. Dit betekent dat u analytics-gegevens verliest over waar uw verkeer vandaan komt. Als uw site op HTTPS staat, behoudt u referrer-gegevens van andere HTTPS-sites.
• Service Workers en PWA: Functies van Progressive Web Apps zoals offline caching, pushmeldingen en de prompt "Toevoegen aan beginscherm" vereisen HTTPS.

Een gratis SSL-certificaat verkrijgen met Let's Encrypt

U hoeft niet te betalen voor een SSL-certificaat. Let's Encrypt biedt gratis, geautomatiseerde, domein-gevalideerde (DV) certificaten die door alle grote browsers worden vertrouwd. De meeste hostingproviders hebben Let's Encrypt geïntegreerd in hun controlepanelen, maar als u uw eigen server beheert, kunt u dit als volgt instellen met Certbot:

# Installeer Certbot op Ubuntu/Debian
sudo apt update
sudo apt install certbot

# Voor Apache
sudo apt install python3-certbot-apache
sudo certbot --apache -d example.com -d www.example.com

# Voor Nginx
sudo apt install python3-certbot-nginx
sudo certbot --nginx -d example.com -d www.example.com

Certbot configureert automatisch uw webserver om het certificaat te gebruiken en stelt een cron-taak in voor automatische verlenging. Let's Encrypt-certificaten zijn 90 dagen geldig, maar het automatische verlengingsproces handelt dit transparant af. Om te verifiëren dat automatische verlenging werkt:

# Test het verlengingsproces (verlengt niet daadwerkelijk)
sudo certbot renew --dry-run

# Controleer de verlengingstimer
sudo systemctl status certbot.timer

Als uw hostingprovider one-click SSL aanbiedt via hun controlepaneel (SiteGround, Bluehost, HostGator, etc.), gebruik dat dan. Het is hetzelfde Let's Encrypt-certificaat, maar beheerd door uw host, wat betekent dat u één ding minder hoeft te onderhouden.

Stap 1: Werk WordPress-URL's bij

Voordat u redirects instelt, vertelt u WordPress dat uw site nu HTTPS gebruikt. Ga naar Instellingen > Algemeen en werk beide velden bij:

• WordPress-adres (URL): Wijzig http://example.com in https://example.com
• Site-adres (URL): Wijzig http://example.com in https://example.com

Als u geen toegang hebt tot het admin-dashboard (bijvoorbeeld als u al vastzit in een redirect loop), kunt u deze waarden direct instellen in wp-config.php:

define('WP_HOME', 'https://example.com');
define('WP_SITEURL', 'https://example.com');

Of werk de database direct bij via WP-CLI:

wp option update siteurl 'https://example.com'
wp option update home 'https://example.com'

Stap 2: HTTP-naar-HTTPS-redirect op serverniveau

De redirect moet plaatsvinden op serverniveau (niet in PHP) om twee redenen: het is sneller omdat het geen WordPress hoeft te laden, en het zorgt ervoor dat alle verzoeken (inclusief statische bestanden, afbeeldingen en API-aanroepen) worden omgeleid, niet alleen door WordPress afgehandelde URL's.

Apache (.htaccess)

Voeg dit helemaal bovenaan uw .htaccess-bestand toe, vóór de WordPress rewrite-regels (vóór de opmerking # BEGIN WordPress):

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

De vlag R=301 stuurt een permanente redirect, die zoekmachines vertelt hun index bij te werken naar de HTTPS-versie. Gebruik niet R=302 (tijdelijke redirect) omdat zoekmachines link-equity dan niet zullen overdragen naar de nieuwe URL.

Nginx

Maak in uw Nginx-configuratie een apart server block voor HTTP dat alles omleidt naar HTTPS:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name example.com www.example.com;

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

    # ... rest van uw configuratie
}

return 301 in Nginx gebruiken is efficiënter dan rewrite gebruiken omdat het geen regex-verwerking vereist.

Stap 3: Forceer HTTPS in wp-config.php

Voeg deze regels toe aan uw wp-config.php-bestand, boven de opmerking "That's all, stop editing!":

// Forceer SSL voor het WordPress-adminpaneel
define('FORCE_SSL_ADMIN', true);

// SSL afhandelen achter een reverse proxy of load balancer
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
    $_SERVER['HTTPS'] = 'on';
}

De constante FORCE_SSL_ADMIN zorgt ervoor dat de WordPress-loginpagina en het admin-dashboard altijd HTTPS gebruiken, zelfs als iemand probeert ze direct via HTTP te benaderen.

Redirect loops achter load balancers en reverse proxies oplossen

Dit is een van de meest voorkomende problemen met WordPress HTTPS-installaties, en het brengt veel mensen in verwarring. Als uw site achter een load balancer, Cloudflare, een reverse proxy of een CDN staat, is de verbinding tussen de proxy en uw server vaak gewoon HTTP, ook al is de verbinding tussen de bezoeker en de proxy HTTPS. Uw server ziet een HTTP-verzoek en probeert om te leiden naar HTTPS, de proxy stuurt het verzoek terug als HTTP, en u eindigt in een oneindige redirect loop. De browser toont "ERR_TOO_MANY_REDIRECTS."

De oplossing is de bovenstaande controle van de X-Forwarded-Proto-koptekst. De proxy voegt deze koptekst toe om uw server te vertellen welk protocol het oorspronkelijke verzoek heeft gebruikt. Wanneer WordPress ziet dat het doorgestuurde protocol HTTPS is, behandelt het de verbinding als beveiligd en activeert het geen redirect.

Als de standaard koptekstcontrole niet werkt, kan uw proxy een andere koptekst gebruiken. Controleer dit bij uw hostingprovider. Veelvoorkomende variaties zijn:

// Voor sommige load balancers die X-Forwarded-Ssl gebruiken
if (isset($_SERVER['HTTP_X_FORWARDED_SSL']) && $_SERVER['HTTP_X_FORWARDED_SSL'] === 'on') {
    $_SERVER['HTTPS'] = 'on';
}

// Voor Cloudflare (dat ook X-Forwarded-Proto instelt, maar voor de zekerheid)
if (isset($_SERVER['HTTP_CF_VISITOR'])) {
    $visitor = json_decode($_SERVER['HTTP_CF_VISITOR']);
    if (isset($visitor->scheme) && $visitor->scheme === 'https') {
        $_SERVER['HTTPS'] = 'on';
    }
}

Stap 4: Vervang HTTP-URL's in de database

Uw WordPress-database bevat hardgecodeerde HTTP-URL's in postinhoud, widgetinstellingen, thema-opties en geserialiseerde gegevens. U moet ze allemaal vervangen door HTTPS-versies. De beste tool hiervoor is het commando search-replace van WP-CLI:

# Voer eerst een dry run uit om te zien wat er zou veranderen
wp search-replace 'http://example.com' 'https://example.com' --all-tables --dry-run

# Als de dry run er goed uitziet, voer de echte vervanging uit
wp search-replace 'http://example.com' 'https://example.com' --all-tables

# Behandel ook www/non-www-variaties indien van toepassing
wp search-replace 'http://www.example.com' 'https://www.example.com' --all-tables

De vlag --dry-run is belangrijk. Het toont u precies hoeveel vervangingen er in elke tabel worden gedaan zonder daadwerkelijk iets te wijzigen. Bekijk de uitvoer voordat u de echte vervanging uitvoert. De vlag --all-tables zorgt ervoor dat aangepaste tabellen (van plug-ins zoals WooCommerce, ACF of paginabouwers) worden opgenomen.

WP-CLI verwerkt geserialiseerde gegevens correct, wat cruciaal is. Als u een eenvoudige SQL find-and-replace probeert, breekt u geserialiseerde arrays omdat de tekenreekslengtewaarden niet langer overeenkomen. Voer voor dit doel nooit een ruwe SQL REPLACE()-query uit.

Mixed-contentproblemen oplossen

Mixed content treedt op wanneer uw HTTPS-pagina bronnen (afbeeldingen, scripts, stylesheets, iframes) over HTTP laadt. Browsers blokkeren actieve mixed content (scripts, stylesheets) volledig en kunnen waarschuwen voor passieve mixed content (afbeeldingen). Dit resulteert in defecte functionaliteit of gele waarschuwingsiconen in de adresbalk.

Om mixed-contentproblemen te vinden:

1. Browserconsole: Open DevTools (F12) en bekijk het tabblad Console. Mixed-contentwaarschuwingen verschijnen als gele of rode meldingen met de exacte URL's van de overtredende bronnen.
2. InspectWP: Voer een scan uit en bekijk de HTML-sectie. InspectWP detecteert onveilige (HTTP) bronnen die op HTTPS-pagina's worden geladen en somt elke bron op.
3. Why No Padlock: De site whynopadlock.com scant uw pagina en rapporteert alle mixed-contentbronnen met hun bron-URL's.

Veelvoorkomende oorzaken van mixed content en hoe deze op te lossen:

• Hardgecodeerde URL's in themabestanden: Doorzoek de PHP- en CSS-bestanden van uw thema op http://-verwijzingen. Vervang ze door https:// of beter nog, gebruik protocol-relatieve URL's (//) of WordPress-functies zoals esc_url().
• Afbeeldingen in postinhoud: Het search-replace-commando van WP-CLI (Stap 4) handelt de meeste hiervan af. Controleer voor hardnekkige gevallen de ruwe HTML in de teksteditor.
• Widgets en Customizer-instellingen: Afbeeldings-URL's in widgets, aangepaste headers en Customizer-instellingen worden opgeslagen als geserialiseerde gegevens. WP-CLI search-replace handelt deze correct af.
• Inhoud van paginabouwers: Elementor, Beaver Builder, Divi en andere paginabouwers slaan hun inhoud op in aangepaste formaten. WP-CLI met --all-tables vangt deze meestal op, maar verifieer door pagina's te laden die met uw paginabouwer zijn gemaakt.
• Externe bronnen: Als u lettertypen, scripts of afbeeldingen laadt vanaf externe domeinen via HTTP, werk die URL's bij. De meeste CDN's en lettertypediensten (Google Fonts, cdnjs, etc.) ondersteunen HTTPS.

Really Simple SSL als alternatief gebruiken

Als de handmatige aanpak overweldigend aanvoelt, automatiseert de plug-in Really Simple SSL het grootste deel van het proces. Installeer het, activeer het, en het zal:

• Uw SSL-certificaat automatisch detecteren.
• De WordPress Site URL en Home URL bijwerken naar HTTPS.
• Een 301-redirect van HTTP naar HTTPS instellen via PHP (of .htaccess indien mogelijk).
• Mixed content oplossen door HTTP-URL's on the fly te vervangen.

Het nadeel van Really Simple SSL is dat het mixed content dynamisch oplost bij elke paginalading, wat een kleine hoeveelheid verwerkingsoverhead toevoegt. Het is beter om de oorzaken op te lossen (database-URL's, hardgecodeerde verwijzingen) en de plug-in vervolgens te verwijderen. Beschouw het als een nuttige brug tijdens migratie, niet als een permanente oplossing.

Stap 5: Voeg de HSTS-koptekst toe

HTTP Strict Transport Security (HSTS) vertelt browsers altijd HTTPS te gebruiken voor uw domein, zelfs als de gebruiker http:// in de adresbalk typt. Nadat u hebt bevestigd dat HTTPS correct werkt op uw site (geen mixed content, geen redirect loops), voegt u de HSTS-koptekst toe:

Apache (.htaccess)

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

Nginx

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

De waarde max-age=31536000 (één jaar) vertelt browsers het HSTS-beleid 12 maanden te onthouden. Begin met een kortere waarde zoals max-age=86400 (één dag) tijdens het testen, en verhoog deze zodra u zeker weet dat alles werkt. De directive includeSubDomains breidt het beleid uit naar alle subdomeinen. Voeg preload alleen toe als u van plan bent uw domein in te dienen bij de HSTS preload-lijst (hstspreload.org), waarmee de HTTPS-vereiste van uw domein in browsers zelf wordt vastgelegd.

HTTPS-configuratie van CDN en Cloudflare

Als u Cloudflare of een ander CDN gebruikt, heeft de HTTPS-configuratie een extra laag van complexiteit:

• Cloudflare Flexible SSL: Verkeer is versleuteld tussen de bezoeker en Cloudflare, maar de verbinding tussen Cloudflare en uw server is gewoon HTTP. Dit is het eenvoudigst in te stellen (geen SSL-certificaat nodig op uw server) maar biedt onvolledige beveiliging. Gegevens tussen Cloudflare en uw server zijn onversleuteld.
• Cloudflare Full SSL: Verkeer is aan beide kanten versleuteld, maar Cloudflare verifieert het certificaat van uw server niet. U hebt een SSL-certificaat op uw server nodig, maar het mag self-signed zijn.
• Cloudflare Full (Strict) SSL: De aanbevolen instelling. Verkeer is aan beide kanten versleuteld en Cloudflare verifieert het certificaat van uw server. Gebruik een geldig Let's Encrypt-certificaat of een Cloudflare Origin Certificate.

Als u overschakelt van Flexible naar Full (Strict), zorg er dan eerst voor dat uw server een geldig SSL-certificaat heeft geïnstalleerd. Anders gaat uw site uit de lucht omdat Cloudflare geen beveiligde verbinding met uw server kan opzetten.

Cloudflare biedt ook "Always Use HTTPS" onder SSL/TLS > Edge Certificates, dat de HTTP-naar-HTTPS-redirect uitvoert aan de Cloudflare-edge. Dit is sneller dan een redirect op uw origin-server omdat de bezoeker uw server nooit bereikt voor het HTTP-verzoek.

SSL-certificaatvervaldatum en automatische verlenging controleren

Een verlopen SSL-certificaat is erger dan helemaal geen certificaat. Browsers tonen een paginagrote waarschuwing waar de meeste bezoekers niet doorheen klikken, en uw site gaat effectief offline. Zo monitort u uw certificaat:

# Controleer de vervaldatum van het certificaat
echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -dates

# Controleer dagen tot vervaldatum
echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -enddate

Als u Let's Encrypt met Certbot gebruikt, moet automatische verlenging automatisch zijn geconfigureerd. Maar verifieer dat het ook echt werkt door de Certbot-verlengingslogboeken te controleren:

# Controleer Certbot-verlengingslogboek
cat /var/log/letsencrypt/letsencrypt.log | tail -20

# Lijst alle certificaten en hun vervaldatums
sudo certbot certificates

Stel voor productiesites monitoring in die u waarschuwt wanneer uw certificaat de vervaldatum nadert. Diensten zoals UptimeRobot, StatusCake of zelfs een eenvoudige cron-taak die de certificaatdatum controleert, kunnen u behoeden voor onverwachte downtime.

Verifieer uw HTTPS-installatie met InspectWP

Voer na het voltooien van de migratie een InspectWP-scan uit om te controleren of alles correct werkt. InspectWP controleert verschillende HTTPS-gerelateerde aspecten:

• SSL/TLS-detectie: Bevestigt dat uw site via HTTPS wordt aangeboden.
• Mixed content: Detecteert HTTP-bronnen (afbeeldingen, scripts, stylesheets) die op uw HTTPS-pagina's worden geladen.
• HSTS-koptekst: Verifieert dat de Strict-Transport-Security-koptekst aanwezig is en correct is geconfigureerd.
• HTTP-redirect: Controleert of de HTTP-versie van uw site correct omleidt naar HTTPS.
• Beveiligingskoptekst: Bekijkt andere beveiligingsgerelateerde koptekst die uw HTTPS-installatie aanvult.

Als InspectWP mixed-contentwaarschuwingen rapporteert, gebruik dan de browserconsole om de specifieke bronnen te identificeren en op te lossen met de hierboven beschreven methoden. Voer na elke oplossing een nieuwe scan uit totdat het rapport schoon terugkomt.