...
webhostinglogo

Redirect loops in WordPress herkennen en herstellen - oorzaken en oplossingen

Ik zal kort en duidelijk uitleggen hoe je een Omleidingslus WordPress en deze betrouwbaar analyseren en oplossen. Ik laat je direct realiseerbare oplossingen zien voor SSL-conflicten, foutieve .htaccess-regels, onjuiste site-URL's, caching/cookies, plugin-problemen en serverinstellingen - inclusief tests en preventie.

Centrale punten

De volgende lijst vat de belangrijkste stappen samen voordat ik de stappen in detail uitleg.

  • Oorzaak snel beperken: SSL, .htaccess, URL's, plugins, cache
  • Standaard-Controleer de regels: .htaccess en wp-config.php
  • HTTPS correct ingesteld: Certificaat, gemengde inhoud, HSTS
  • Plugins Uitschakelen op testbasis: via dashboard of FTP
  • Preventie inrichten: Back-ups, documentatie, monitoring

Wat betekent een omleidingslus eigenlijk?

A Doorschakellus treedt op wanneer URL A naar URL B springt en B terugspringt naar A - of wanneer meerdere sprongen terugleiden naar het startadres aan het einde. De browser annuleert dan met ERR_TOO_MANY_REDIRECTS en blokkeert de aanroep. Ik herken de lus vaak aan het feit dat de login het loginformulier opnieuw laadt na correcte invoer. Voor bezoekers ziet dit eruit als een eindeloze ronde, voor zoekmachines als een technische fout. Dit kost vertrouwen, voorkomt inloggen op de backend en vreet kostbaar crawlbudget op.

Belangrijkste oorzaken van loops in WordPress

Ik vind de meest voorkomende triggers in vals WordPress URL's, agressieve .htaccess regels, dubbele SSL afdwingingen of chaotische plugin redirects. Oude cookies en harde browsercaches sturen verzoeken ook op een dwaalspoor. Na domeinwijzigingen of HTTPS-conversies komen fouten vaker voor omdat http en https worden gemengd. In thema's met eigen omleidingen of beveiligingsplugins kunnen regels elkaar blokkeren. In zeldzame gevallen stelt malware opzettelijk omleidingen in om beheerders uit te sluiten.

Snelle tests in de browser: Cookies en cache

Ik begin met een Klant-check, omdat het binnen enkele minuten duidelijkheid brengt. Ik verwijder cookies en de hele cache voor het betreffende domein. Een privévenster helpt om oude sessies uit te sluiten. Als het inloggen dan werkt, lag het aan lokale gegevens en niet aan de server. Als de fout zich blijft voordoen, ga ik naar het server- en WordPress-niveau.

Controleer .htaccess en reset naar standaard

Ik beveilig de .htaccess en zet ze als test terug naar de WordPress-standaard. Zo verwijder ik conflicterende redirects uit eerdere experimenten of SEO-regels.

# BEGIN WordPress
RewriteEngine Aan
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !.-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# EINDE WordPress

Zodra alles werkt, zal ik stap voor stap extra omleidingen toevoegen. Voor schone voorwaarden verwijs ik naar htaccess omleidingen met praktische voorbeelden. Belangrijk: Forceer http→https nooit twee keer - één keer op serverniveau is genoeg.

WordPress URL's aanpassen in instellingen en wp-config.php

Afwijkingen tussen WP_HOME en WP_SITEURL veroorzaken vaak eindeloze loops, vooral na domeinverhuizingen. Ik controleer eerst Instellingen > Algemeen. Als de backend niet toegankelijk is, stel ik de waarden even in wp-config.php in:

define( "WP_HOME", "https://deinedomain.de" );
define("WP_SITEURL", "https://deinedomain.de" );

In het geval van SSL-problemen bij de beheerder, deblokkeer ik ook tijdelijk de toegang:

define('FORCE_SSL_ADMIN', false);

Zodra ik in het dashboard ben, stel ik de juiste URL's in en verwijder ik de constanten weer. Gestandaardiseerde adressen voorkomen herhaalde lussen.

HTTPS/SSL-conflicten netjes oplossen

Conflicten ontstaan wanneer SSL wordt afgedwongen aan de serverkant en een plugin stelt ook redirects in. Ik test eerst of het certificaat geldig is en of HSTS of proxy headers de herkenning verstoren. Vervolgens zorg ik ervoor dat er een duidelijke locatie is die https afdwingt - bij voorkeur op serverniveau. Fouten met gemengde inhoud en onjuiste doorstuurketens elimineer ik consequent. Voor de daadwerkelijke overstap helpt deze gids me om HTTPS-conversie in WordPress.

Plugins en thema's beperken als bron van fouten

Ik schakel achterdochtig in Plugins vooral redirect-, SEO- en beveiligingstools. Als ik niet in de backend kan komen, hernoem ik de map wp-content/plugins via FTP naar plugins.old. Vervolgens activeer ik elke plugin afzonderlijk in het dashboard totdat de foutmelding weer verschijnt. Overschakelen naar een standaard thema zoals Twenty Twenty-Four laat ook zien of het thema regels bijdraagt. Zo kan ik snel de oorzaak vinden en een conflictvrije configuratie maken.

Een einde maken aan aanmeldingslussen: Cookies, Sessies, Beveiliging

Als het aanmelden mislukt ondanks correct Gegevens springt weer terug, ik controleer het cookie-domein, het pad en de https-vlag. Ik wis caches op alle niveaus: Browser, WordPress cache, object cache, CDN. Voor beveiligingsplugins controleer ik regels die admin URL's omleiden of logins beperken. Ik stel tijdelijk duidelijke standaardwaarden in voor diagnostiek en bouw dan beetje bij beetje de beveiliging opnieuw op. Doel: Een stabiele sessie zonder dubbele redirects.

Stel reverse proxy, CDN en serverheader correct in

Achter een Proxy Applicaties verwarren http en https gemakkelijk als de Forwarded of X-Forwarded-Proto header ontbreekt of onjuist aankomt. Ik controleer Nginx/Apache-configuraties, loadbalancer-instellingen en CDN-forwarding. Het is belangrijk dat WordPress de werkelijke URL van de client correct herkent. Voor opstellingen met een upstream proxy helpt deze handleiding me om Reverse proxy instellen. Dit voorkomt tegenstrijdige regels tussen server, CDN en plugin.

Malware als laatste bron van verdenking

Als de lus ondanks alle correcties nog steeds kan worden gesloten niet Ik scan de installatie op kwaadaardige code. Ik vergelijk kernbestanden met originelen, controleer nieuwere admins en cron jobs. Ik leg redirects bloot in headers, sjabloonbestanden of via JavaScript door te zoeken naar window.location, meta refresh of obscure Base64 strings. Na het opschonen reset ik wachtwoorden en maak ik een nieuwe back-up. Beveiliging tegen herinfectie bespaart later veel tijd.

Profylaxe en monitoring in het dagelijks leven

Ik voorkom lussen door Veranderingen redirects centraal beheren en ze testen in een staging-omgeving voordat ze live worden geïnstalleerd. Ik maak automatisch back-ups en houd plugins en thema's up-to-date. Na domeinwijzigingen controleer ik de URL's van de site, SSL en redirectketens. Een klein monitoringsysteem waarschuwt me in een vroeg stadium voor sprongen in de statuscode. De volgende tabel helpt bij een snelle diagnose tijdens het gebruik.

Symptoom Mogelijke oorzaak Directe maatregel Testgereedschap
ERR_TE_VEEL_OMLEIDINGEN Dubbele handhaving https Gebruik slechts één locatie voor omleidingen HTTP-headercontrole, Curl
Inloggen springt terug Cookie/sessie conflict Cookies verwijderen, cache legen Privévenster, DevTools
Startpagina wordt niet geladen .htaccess lus Standaard .htaccess activeren Serverlogboeken, diff
Alleen defect onder volmacht Onjuiste Proto-header X-Forwarded-Proto correct instellen Proxy-config, koptrace
Plotseling van ranglijst Kettingen omleiden Kettingen verminderen, 301 corrigeren Kruiper, Schreeuwkikker

Volg omleidingen nauwkeurig: Header traceren en curl

Voordat ik overga tot configuraties, teken ik de exacte keten naar. In DevTools (tabblad Netwerk) kun je elke hop zien met statuscode en locatieheader. Op de shell is vaak voldoende:

curl -IL https://deinedomain.de
# of gedetailleerd met weergave van elke omleiding
curl -IL --max-redirs 20 https://deinedomain.de

Ik let op patronen zoals http→https→http (heen-en-weer) of www↔non-www. Een 302 na een 301 is ook verdacht. Als zelfs het eerste verzoek doorverwijst naar /wp-login.php, ligt de oorzaak meestal in de plugin/theme of cookies; als het globaal gebeurt, is het vaak .htaccess of de server.

Gericht gebruik van server- en WordPress-logs

Logs besparen uren. Ik activeer het debug-log in wp-config.php zonder het weer te geven aan bezoekers:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);

Vervolgens controleer ik /wp-content/debug.log op aanwijzingen (bijv. "Kan header-informatie niet wijzigen" voor een redirect). Tegelijkertijd controleer ik de logs van de webserver. Voor Apache: access.log en error.log, voor Nginx: access.log met status 301/302. Een blik op de user agent helpt om te bepalen of alleen bots of alle gebruikers getroffen zijn.

WP-CLI: snelle redding via console

Als het dashboard niet toegankelijk is, los ik veel dingen op via WP-CLI:

# URL's controleren en instellen
wp optie get home
wp optie get siteurl
wp optie update home 'https://deinedomain.de'
wp optie update siteurl 'https://deinedomain.de'

# "Sla door" permalinks eenmalig
wp herschrijven --hard

# Leeg caches
wp cache spoelen
wp tijdelijk verwijderen --alle

# Plugins massaal deactiveren / testen
wp plugin deactiveren --alle
wp plugin klassieke-editor activeren

Op deze manier kan ik zonder risico terug naar het systeem, de boosdoeners vinden en alleen activeren wat echt nodig is.

www, slash en canonisatie zonder lus

Lussen worden vaak gemaakt van kleine inconsistentieswww vs. niet-www, ontbrekende/extra schuine streep of gemengd proto. Ik kies voor één variant en stel alleen a Regelketen. Voorbeeld niet-www→www in Apache (zonder dubbele https-handhaving):

RewriteEngine Aan
# Alleen doorsturen als host nog geen www is
RewriteCond %{HTTP_HOST} !^www. [NC]
RewriteRule ^(.*)$ https://www.%{HTTP_HOST}/$1 [L,R=301]

Met Nginx stel ik een duidelijke server block forwarding in en vermijd ik gemengde regels in PHP/plugins. Belangrijk: Eerst de canonicalisatie (www/slash), dan https - en alleen naar a Positie.

Schoon achter proxy/CDN: HTTPS correct herkennen

Als WordPress achter een loadbalancer of CDN zit, ontvangt de backend vaak alleen http, hoewel de client https gebruikt. WordPress herkent is_ssl() dan verkeerd en genereert loops. Ik corrigeer de servervariabelen vroeg in de wp-config.php:

if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
    $_SERVER['HTTPS'] = 'on';
}

Ik stel ook de headers X-Forwarded-Proto en Forwarded clean in op de proxy. Ik gebruik HSTS spaarzaam: Als HSTS actief is, kan het geen http-pad, anders hangt de browser. Ik gebruik preload alleen als alle subdomeinen stabiel op https draaien.

Inlog- en cookievallen onschadelijk maken

Een veelvoorkomende bron zijn verkeerd ingestelde cookies. Ik stel meestal geen COOKIE_DOMAIN. Als het al een keer is gedefinieerd, verander ik het als test:

define('COOKIE_DOMAIN', false);

Ik controleer ook of de admin cookie flag "Secure" is ingesteld onder https en of het pad is ingesteld op "/". Bij aanhoudende problemen verwijder ik server-side sessies (bijv. php-fpm herstarten) en leeg ik de object cache/redis zodat oude nonces niet meer van kracht zijn.

Speciale kenmerken van multisite- en domeintoewijzing

Op Multisite-instellingen leiden verschillende mappings al snel tot een lus: Subdomein vs. directory modus, verschillende protocollen of een oude domain mapping plugin met zijn eigen redirects. Ik controleer de blog- en sitetabellen, synchroniseer protocollen en hosts en schakel de automatische doorverwijzingen voor taalomschakeling even uit. Een "Super Admin" login in het hoofdblog helpt om de netwerkomleidingen centraal te zien. Belangrijk: Slechts één instantie beslist over het canonieke domein.

WooCommerce, meertaligheid en "Verberg login"

Winkels en meertalige sites hebben extra omleidingslogica: geforceerde SSL-pagina's (kassa/account), taalomleiding naar Accept-Language of "Hide Login"-functies in beveiligingsplugins. Voor de diagnose schakel ik de automatische taalomleiding uit en sta ik tijdelijk /wp-login.php toe zonder omleiding. In WooCommerce stel ik "Alleen deze pagina's op SSL" netjes in aan de serverkant of volledig systeembreed, zodat er geen gemengde toestanden ontstaan.

Coördinaat object cache, opcode en edge cache

Verschillende cachinglagen kunnen elkaar versterken: PHP opcode (OPcache), object cache (Redis/Memcached), pagina cache van plugins en CDN edge. Ik leeg ze in een ordelijke volgorde zodat geen enkele laag oude redirects retourneert. Na regelwijzigingen maak ik de edge cache volledig ongeldig. Alleen dan is een test zinvol.

Typische Nginx valstrikken

Met Nginx treden loops op wanneer locatieblokken twee keer worden herschreven of /index.php intern en extern leeft. Ik gebruik een enkele schone configuratie: eerst de server block forwarding (www/https), dan een duidelijke try_files op /index.php. Ik vermijd consequent mengsels van add_header refresh en 301/302.

Checklist: vind de oorzaak in 10 minuten

  • Verwijder cookies/cache lokaal, test in incognitomodus
  • Voer curl -IL uit en bekijk de keten
  • Zet .htaccess/Nginx terug naar het standaardpad
  • WP_HOME/WP_SITEURL synchroniseren (indien nodig via WP-CLI)
  • Slechts één instantie dwingt https af (voorkeur voor server)
  • Plugins/thema deactiveren, stap voor stap activeren
  • Stel proxy-header correct in, controleer is_ssl()
  • Leeg object/pagina/rand cache
  • Controleer logboeken: debug.log, access/error.log
  • Speciale functies: Multisite, Woo, Talen, Hide-Login

Foutpatronen buiten klassieke lussen

Niet elke 301/302 is een echte lus - maar Verkeerd omleiden kosten ook. Een 301 naar 404 geeft zoekmachines het signaal "deze bron is hier voor altijd", maar levert leegte op. Of een 302 in plaats van 301 voorkomt de permanente consolidatie van signalen. Ik houd de keten op maximaal een of twee niveaus, stel 301 in voor permanente en 302 voor tijdelijke gevallen en voorkom query string-verliezen door QSA-flags of -argumenten correct door te geven.

Stabiele implementaties en documentatie

Om te voorkomen dat er lussen ontstaan, documenteer ik elke regelWie routeert wat naar waar - en waarom? Ik gebruik een staging-omgeving, speel daar met regelwijzigingen, log headers en tijden en distribueer dan identieke server- en plugin-instellingen in productie. Een korte post-deployment controle (startpagina, login, checkout, taal) voorkomt mislukkingen.

Conclusie in het kort

Ik breng een Doorschakellus Systematisch: cookies controleren, .htaccess terugzetten naar standaard, WP URL's aanpassen, SSL correct instellen, plugins/thema's isoleren en serverheaders correct aanleveren. Deze stappen beëindigen de lus meestal in korte tijd. Vervolgens beveilig ik de installatie, documenteer redirects en houd updates up-to-date. Zo blijft de login toegankelijk, landen bezoekers op de juiste pagina's en crawlen zoekmachines zonder tijd te verliezen. Een gestructureerde aanpak voorkomt herhalingen - en spaart zenuwen.

Huidige artikelen