Redirectfouten

Redirect statuscodes

Statuscodes die met een 3 beginnen, zijn op zichzelf geen fouten maar slaan op redirects, oftewel omleidingen. Ze vertellen de browser dat de gevraagde content ergens anders staat, of dat die niet is veranderd sinds de browser hem voor het laatst laadde. Je ziet ze in de access.log van je site en als je een URL natrekt met curl -IL. Je hoeft er pas iets mee als ze bezoekers naar de verkeerde plek sturen of in een loop terechtkomen.

301 Moved Permanently

Een 301 redirect vertelt browsers en zoekmachines dat een pagina definitief is verhuisd. Je site gebruikt ze voor HTTPS, voor je primaire domein (met of zonder www.) en om een slash toe te voegen aan URL’s van mappen. Met redirectregels kun je er ook zelf toevoegen.

Browsers onthouden 301 redirects. Wijzig of verwijder je er een, leeg dan de cache van je browser of test in een privévenster om het nieuwe gedrag te zien. Gaat een URL door meerdere 301’s voordat hij laadt, laat de eerste redirect dan direct naar de uiteindelijke URL wijzen.

302 Found

Een 302 redirect is tijdelijk, dus browsers en zoekmachines onthouden hem niet. WordPress en plugins gebruiken ze voor dingen die per bezoek verschillen. Denk aan uitgelogde gebruikers die van /wp-admin/ naar de inlogpagina gaan, een redirect na het versturen van een formulier, of bezoekers die naar een taal- of landversie van een pagina gaan.

Is een pagina definitief verhuisd, gebruik dan een 301. Zoekmachines werken hun gegevens dan bij en geven de ranking van de oude pagina door aan de nieuwe.

304 Not Modified

Een 304 is geen redirect. Hij betekent dat de browser van de bezoeker al een kopie van het bestand heeft en dat je site heeft bevestigd dat het niet is veranderd. De browser gebruikt dan zijn eigen kopie in plaats van het bestand opnieuw te downloaden. 304’s in je access.log zijn normaal en betekenen dat caching werkt.

Heb je een bestand gewijzigd en zien bezoekers nog steeds de oude versie, leeg dan de cache van je site en een eventuele CDN cache.

Te veel redirects

Een “too many redirects” fout betekent dat een pagina blijft doorverwijzen in plaats van te laden. Meestal wijzen twee instellingen naar elkaar: de ene stuurt bezoekers naar adres A, de andere stuurt ze terug naar adres B, en na een vast aantal pogingen geeft de browser het op. Browsers tonen dit als ERR_TOO_MANY_REDIRECTS of met een melding als “redirected you too many times”.

Een redirectloop komt bijna altijd door de configuratie van je site, niet door een tijdelijk probleem. Hij lost zich dus niet vanzelf op. Vaak begint hij direct na een wijziging aan SSL, domeinen, een CDN of redirectregels.

De twee adressen vinden die een loop vormen

Als je de redirects natrekt, zie je tussen welke twee adressen de request heen en weer gaat. Dat wijst naar de oorzaak.

1. Voer curl -IL https://jouwdomein.com uit in een terminal, of vul je URL in bij een online redirectchecker.
2. Bekijk de Location-waarde in elk antwoord. Dat zijn de adressen waar de request naartoe wordt gestuurd.
3. Vergelijk de adressen die terugkomen:
   • Alleen http:// en https:// verschillen: zie Loops tussen HTTP en HTTPS.
   • Alleen www. verschilt: zie Loops tussen www en zonder www.
   • De paden verschillen, zoals /shop/ en /store/: zie Conflicterende redirectregels.

Kun je deze controles niet uitvoeren, begin dan bij wat je het laatst hebt gewijzigd.

Loops tussen HTTP en HTTPS

Dit is de meest voorkomende redirectloop. De ene laag stuurt bezoekers naar https://, de andere stuurt de request terug naar http://.

1. Je eigen Cloudflare account op Flexible SSL: Gebruik je je eigen Cloudflare account vóór Kinsta, controleer dan de SSL/TLS encryption mode in je Cloudflare dashboard. In de modus Flexible maakt Cloudflare via HTTP verbinding met je site, en je site stuurt die request door naar HTTPS. Dat herhaalt zich eindeloos. Zet de modus op Full (strict). Je Kinsta site heeft al een SSL certificaat.
2. Een ander CDN of een andere proxy: Gebruik je een ander CDN of een andere proxy van een derde partij, zorg dan dat die via HTTPS verbinding maakt met Kinsta, niet via HTTP. Staat HTTPS forceren aan in MyKinsta en weet je niet welke laag de loop veroorzaakt, zet HTTPS forceren dan tijdelijk uit om te testen.
3. Een redirect van HTTPS naar HTTP: Zoek in je redirectregels en plugins naar iets wat bezoekers van https:// naar http:// stuurt, en verwijder dat.

Loops tussen www en zonder www

De ene instelling stuurt bezoekers naar www.example.com, de andere stuurt ze terug naar example.com. Dit gebeurt meestal na een migratie of een domeinwijziging.

1. Bepaal welke versie van je domein de hoofdversie is: met of zonder www.
2. Controleer in MyKinsta of die versie is ingesteld als primair domein van je site.
3. Ga in WordPress naar Settings > General en controleer of WordPress Address (URL) en Site Address (URL) allebei precies die versie gebruiken, inclusief https://.
4. Zijn die velden grijs, dan zijn de URL’s met WP_HOME en WP_SITEURL ingesteld in het configuratiebestand van WordPress (wp-config.php in de hoofdmap van je site), en die gaan voor op de instellingen in het dashboard. Pas ze daar aan.

Kun je niet bij het WordPress dashboard, controleer en wijzig de URL’s dan met WP-CLI: wp option get siteurl en wp option get home tonen de huidige waarden, en met wp option update wijzig je ze.

Conflicterende redirectregels

Twee redirectregels wijzen naar elkaar, vaak omdat dezelfde redirect op meer dan één plek is ingesteld. Controleer elke plek waar je redirects kunt instellen en zet elke redirect maar op één plek:

• Redirectregels in MyKinsta.
• Redirect plugins in WordPress.
• Page rules of redirect rules in een CDN van een derde partij, zoals je eigen Cloudflare account.

Plugins

SSL-, redirect-, beveiligings- en cachingplugins kunnen elk hun eigen redirects toevoegen, en die kunnen botsen met elkaar of met je serverinstellingen. Is de loop begonnen nadat je een plugin hebt geïnstalleerd, bijgewerkt of anders ingesteld, deactiveer die plugin dan. Kun je niet bij het WordPress dashboard, deactiveer hem dan met WP-CLI (wp plugin deactivate plugin-name) of door de map via SFTP te hernoemen.

Staat HTTPS forceren aan in MyKinsta, dan is een plugin die ook HTTPS forceert overbodig en een veelvoorkomende oorzaak van loops. Gebruik het een of het ander, niet allebei.

Als onze monitoring een loop meldt maar je site wel laadt

De uptimemonitoring van Kinsta controleert je site zoals een nieuwe bezoeker dat zou doen, zonder cookies of opgeslagen sessie. Kreeg je een melding over een redirect maar laadt je site normaal in je browser, dan treft de loop misschien alleen nieuwe bezoekers:

• Redirects op basis van cookies: Redirects voor taal of locatie, leeftijdscontroles en cookietoestemmingspagina’s kunnen bezoekers blijven doorsturen tot er een cookie is gezet. Bezoekers die cookies blokkeren, en ook zoekmachines en monitoringtools, kunnen dan in een loop belanden.
• Je eigen browser: Open je site in een privé- of incognitovenster om hem te zien zoals een nieuwe bezoeker.

Nadat je de loop hebt opgelost

Browsers bewaren permanente (301) redirects, dus de fout kan in je browser blijven verschijnen nadat de oorzaak al is opgelost.

1. Leeg de cache van je site in MyKinsta en een eventuele CDN cache.
2. Wis de cache en cookies van je browser voor je site, of test in een privé- of incognitovenster.

Wanneer neem je contact op met support?

Vind je de oorzaak niet, of gaat de loop door nadat je deze instellingen hebt gecontroleerd? Neem dan contact op met support en geef de URL door, de uitvoer van curl -IL of je redirectchecker, en de wijzigingen die je onlangs hebt gemaakt.