Videre til indhold 
Jeg forklarer kort og klart, hvordan du kan skabe en Omdirigeringssløjfe WordPress og analysere og løse dem på en pålidelig måde. Jeg vil vise dig umiddelbart realiserbare løsninger på SSL-konflikter, forkerte .htaccess-regler, forkerte webadresser, caching/cookies, plugin-problemer og serverindstillinger - inklusive test og forebyggelse.
Centrale punkter
Den følgende liste opsummerer de vigtigste trin, før jeg forklarer dem i detaljer.
- Årsag hurtigt indsnævre: SSL, .htaccess, URL'er, plugins, cache
- Standard-Tjek regler: .htaccess og wp-config.php
- HTTPS indstillet korrekt: Certifikat, blandet indhold, HSTS
- Plugins Sluk på testbasis: via dashboard eller FTP
- Forebyggelse etablere: Sikkerhedskopier, dokumentation, overvågning
Hvad betyder et redirect-loop egentlig?
En Forwarding loop opstår, når URL A springer til URL B, og B springer tilbage til A - eller når flere spring fører tilbage til startadressen i slutningen. Browseren annullerer derefter med ERR_TOO_MANY_REDIRECTS og blokerer kaldet. Jeg genkender ofte loopet ved, at login indlæser login-formularen igen efter korrekt indtastning. For besøgende ser det ud som en endeløs runde, for søgemaskiner som en teknisk fejl. Det koster tillid, forhindrer logins til backend og æder værdifulde crawl-budgetter.
Hovedårsager til loops i WordPress
Jeg finder de hyppigste triggere i falsk WordPress-URL'er, aggressive .htaccess-regler, dobbelt SSL-håndhævelse eller kaotiske plugin-omdirigeringer. Gamle cookies og hårde browsercacher sender også anmodninger på afveje. Efter domæneændringer eller HTTPS-konverteringer opstår der oftere fejl, fordi http og https blandes. I temaer med deres egne omdirigeringer eller sikkerhedsplugins kan reglerne blokere hinanden. I sjældne tilfælde indstiller malware bevidst omdirigeringer for at låse administratorer ude.
Hurtige tests i browseren: Cookies og cache
Jeg starter med en Kunde-tjek, fordi det giver klarhed på få minutter. Jeg sletter cookies og hele cachen for det berørte domæne. Et privat vindue hjælper med at udelukke gamle sessioner. Hvis login derefter fungerer, skyldes det lokale data og ikke serveren. Hvis fejlen fortsat opstår, går jeg til server- og WordPress-niveau.
Tjek .htaccess og nulstil til standard
Jeg sikrer mig .htaccess og nulstiller dem til WordPress-standarden som en test. Det er sådan, jeg fjerner modstridende omdirigeringer fra tidligere eksperimenter eller SEO-regler.
# BEGIN WordPress
RewriteEngine On
RewriteBase /.
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# SLUT WordPress
Når alt er oppe at køre, vil jeg tilføje yderligere omdirigeringer trin for trin. For rene forhold henviser jeg til htaccess-omdirigeringer med praktiske eksempler. Vigtigt: Tving aldrig http→https to gange - én gang på serverniveau er nok.
Tilpas WordPress-URL'er i indstillinger og wp-config.php
Afvigelser mellem WP_HOME og WP_SITEURL udløser ofte endeløse loops, især efter domæneoverførsler. Jeg tjekker først Indstillinger > Generelt. Hvis backend ikke er tilgængelig, indstiller jeg kort værdierne i wp-config.php:
define( 'WP_HOME', 'https://deinedomain.de' );
define( 'WP_SITEURL', 'https://deinedomain.de' );
I tilfælde af SSL-problemer hos administratoren fjerner jeg også midlertidigt blokeringen af adgangen:
define('FORCE_SSL_ADMIN', false);
Så snart jeg er i dashboardet, indstiller jeg korrekte URL'er og fjerner konstanterne igen. Standardiserede adresser forhindrer gentagne loops.
Løs HTTPS/SSL-konflikter på en ren måde
Konflikter opstår, når SSL håndhæves på serversiden, og et plugin indstiller også omdirigeringer. Jeg tester først, om certifikatet er gyldigt, og om HSTS eller proxy-headere forstyrrer genkendelsen. Derefter sikrer jeg, at der er et klart sted, der håndhæver https - helst på serverniveau. Jeg eliminerer konsekvent fejl med blandet indhold og forkerte videresendelseskæder. Til den faktiske overgang hjælper disse instruktioner mig med at HTTPS-konvertering i WordPress.
Begrænsning af plugins og temaer som fejlkilde
Jeg tænder for mistænkelige Plugins især redirect-, SEO- og sikkerhedsværktøjer. Hvis jeg ikke kan komme ind i backend, omdøber jeg wp-content/plugins-mappen til plugins.old via FTP. Derefter aktiverer jeg hvert enkelt plugin i dashboardet, indtil fejlen dukker op igen. Når jeg skifter til et standardtema som Twenty Twenty-Four, kan jeg også se, om temaet bidrager med regler. Det giver mig mulighed for hurtigt at finde årsagen og skabe en konfliktfri konfiguration.
Slut med login-loops: Cookies, sessioner, sikkerhed
Hvis login mislykkes på trods af korrekt Data hopper tilbage igen, jeg tjekker cookie-domænet, stien og https-flaget. Jeg rydder cacher på alle niveauer: Browser, WordPress-cache, objektcache, CDN. For sikkerhedsplugins tjekker jeg regler, der omdirigerer administrator-URL'er eller begrænser logins. Jeg indstiller midlertidigt klare standardindstillinger til diagnosticering og genopbygger derefter sikkerheden lidt efter lidt. Mål: En stabil session uden dobbelte omdirigeringer.
Indstil reverse proxy, CDN og serverheader korrekt
Bag en Proxy Applikationer kan nemt forveksle http og https, hvis Forwarded- eller X-Forwarded-Proto-headeren mangler eller ankommer forkert. Jeg tjekker Nginx/Apache-konfigurationer, load balancer-indstillinger og CDN-forwarding. Det er vigtigt, at WordPress genkender den faktiske klient-URL korrekt. For opsætninger med en upstream-proxy hjælper denne guide mig med at Opsæt omvendt proxy. Dette forhindrer modstridende regler mellem server, CDN og plugin.
Malware som den sidste kilde til mistanke
Hvis sløjfen stadig kan lukkes på trods af alle korrektionerne ikke Jeg scanner installationen for ondsindet kode. Jeg sammenligner kernefiler med originaler, tjekker nyere administratorer og cron-jobs. Jeg afslører omdirigeringer i overskrifter, skabelonfiler eller via JavaScript ved at søge efter window.location, meta refresh eller obskure Base64-strenge. Efter oprydningen nulstiller jeg adgangskoder og tager en ny backup. Sikkerhed mod geninfektion sparer en masse tid senere.
Forebyggelse og overvågning i hverdagen
Jeg forhindrer loops ved at Ændringer administrerer omdirigeringer centralt og tester dem i et scenemiljø, før de implementeres live. Jeg opretter automatisk sikkerhedskopier og holder plugins og temaer opdaterede. Efter domæneændringer tjekker jeg webstedets URL'er, SSL og omdirigeringskæder. Et lille overvågningssystem giver mig besked om statuskodespring på et tidligt tidspunkt. Følgende tabel hjælper med hurtig diagnosticering under drift.
| Symptom | Mulig årsag | Direkte foranstaltning | Testværktøj |
|---|---|---|---|
| ERR_TOO_MANY_REDIRECTS | Dobbelt https-håndhævelse | Brug kun én placering til omdirigeringer | Kontrol af HTTP-overskrift, Curl |
| Login springer tilbage | Konflikt mellem cookie og session | Slet cookies, tøm cache | Privat vindue, DevTools |
| Startsiden indlæses ikke | .htaccess-løkke | Aktivér standard .htaccess | Serverlogs, diff |
| Kun fejl under fuldmagt | Forkert Proto-overskrift | Indstil X-Forwarded-Proto korrekt | Proxy-konfiguration, Header-sporing |
| Pludselig fra ranking | Omdirigeringskæder | Reducer kæder, 301 korrekt | Crawler, skrigende frø |
Spor omdirigeringer præcist: Header trace og curl
Før jeg går over til konfigurationer, tegner jeg præcis kæde til. I DevTools (fanebladet Network) kan du se hvert hop med statuskode og placeringsoverskrift. On the shell er ofte tilstrækkeligt:
curl -IL https://deinedomain.de
# eller detaljeret med visning af hver omdirigering
curl -IL --max-redirs 20 https://deinedomain.de
Jeg holder øje med mønstre som http→https→http (frem og tilbage) eller www↔non-www. En 302 efter en 301 er også mistænkelig. Hvis selv den første anmodning omdirigerer til /wp-login.php, er årsagen normalt i plugin/tema eller cookies; hvis det sker globalt, er det ofte .htaccess eller serveren.
Målrettet brug af server- og WordPress-logfiler
Logs sparer timer. Jeg aktiverer debug-loggen i wp-config.php uden at vise den til de besøgende:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);
Derefter tjekker jeg /wp-content/debug.log for indikationer (f.eks. "Cannot modify header information" før en omdirigering). Samtidig tjekker jeg webserverens logfiler. For Apache: access.log og error.log, for Nginx: access.log med status 301/302. Et kig på brugeragenten hjælper med at afgøre, om det kun er bots eller alle brugere, der er berørt.
WP-CLI: hurtig redning via konsollen
Hvis instrumentbrættet ikke er tilgængeligt, løser jeg mange ting via WP-CLI:
# Tjek og indstil URL'er
wp option get home
wp mulighed få siteurl
wp option update home 'https://deinedomain.de'
wp option update siteurl 'https://deinedomain.de'
# "Gem gennem" permalinks én gang
wp rewrite flush --hard
# Tøm cacher
wp cache flush
wp forbigående sletning --alle
# Deaktiver / test plugins en masse
wp-plugin deaktiveres --alle
wp-plugin aktiver classic-editor
På den måde kan jeg komme tilbage til systemet uden risiko, finde synderne og kun aktivere det, der virkelig er brug for.
www, skråstreg og kanonisering uden loop
Loops skabes ofte ud fra små uoverensstemmelserwww vs. ikke-www, manglende/yderligere slash eller blandet proto. Jeg beslutter mig for én variant og sætter kun en Regelkæde. Eksempel på non-www→www i Apache (uden dobbelt https-håndhævelse):
RewriteEngine On
# Videresend kun, hvis værten ikke allerede er www
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^(.*)$ https://www.%{HTTP_HOST}/$1 [L,R=301]
Med Nginx sætter jeg en klar server block forwarding og undgår blandede regler i PHP/plugins. Vigtigt: Først kanonisering (www/slash), så https - og kun til en Position.
Ren bag proxy/CDN: Genkender HTTPS korrekt
Hvis WordPress er bag en load balancer eller CDN, modtager backend ofte kun http, selvom klienten bruger https. WordPress genkender så is_ssl() forkert og genererer loops. Jeg korrigerer servervariablerne tidligt i wp-config.php:
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
$_SERVER['HTTPS'] = 'on';
}
Jeg sætter også overskrifterne X-Forwarded-Proto og Forwarded clean på proxyen. Jeg bruger HSTS sparsomt: Hvis HSTS er aktiv, kan det ingen http-sti, ellers hænger browseren. Jeg bruger kun preload, når alle underdomæner kører stabilt på https.
Uskadeliggør login- og cookie-fælder
En almindelig kilde er forkert indstillede cookies. Jeg indstiller normalt ingen COOKIE_DOMAIN. Hvis det er blevet defineret én gang, ændrer jeg det som en test:
define('COOKIE_DOMAIN', false);
Jeg tjekker også, om admin-cookie-flaget "Secure" er sat under https, og om stien er sat til "/". I tilfælde af vedvarende problemer sletter jeg sessioner på serversiden (f.eks. ved at genstarte php-fpm) og tømmer objektcachen/redis, så gamle nonces ikke længere træder i kraft.
Særlige funktioner ved multisite- og domænekortlægning
På Multisite-opsætninger fører forskellige mappinger hurtigt til en løkke: Subdomain vs. directory mode, forskellige protokoller eller et gammelt domain mapping plugin med sine egne redirects. Jeg tjekker blog- og sidetabellerne, synkroniserer protokoller og hosts og deaktiverer kortvarigt automatiske omdirigeringer for at skifte sprog. Et "Super Admin"-login på hovedbloggen hjælper med at se netværksomdirigeringer centralt. Vigtigt: Kun én instans bestemmer det kanoniske domæne.
WooCommerce, flersprogethed og "Skjul login"
Butikker og flersprogede websteder har yderligere omdirigeringslogik: tvungne SSL-sider (checkout/konto), sprogomdirigering til Accept-Language eller "Hide Login"-funktioner i sikkerhedsplugins. Til diagnosen deaktiverer jeg den automatiske sprogomdirigering og tillader midlertidigt /wp-login.php uden omdirigering. I WooCommerce indstiller jeg "Kun disse sider på SSL" enten rent på serversiden eller helt i hele systemet, så der ikke opstår blandede tilstande.
Koordinatobjekt-cache, opcode- og edge-cache
Flere cachelag kan hinanden amplify: PHP opcode (OPcache), objektcache (Redis/Memcached), sidecache for plugins og CDN edge. Jeg tømmer dem i en ordnet rækkefølge, så intet lag returnerer gamle omdirigeringer. Efter regelændringer invaliderer jeg edge-cachen fuldstændigt. Først da er en test meningsfuld.
Typiske Nginx-fælder
Med Nginx opstår der loops, når placeringsblokke omskrives to gange, eller /index.php lever internt og eksternt. Jeg bruger en enkelt ren konfiguration: først serverens blokforwarding (www/https), derefter en klar try_files på /index.php. Jeg undgår konsekvent blandinger af add_header refresh og 301/302.
Tjekliste: Find årsagen på 10 minutter
- Slet cookies/cache lokalt, test i inkognitotilstand
- kør curl -IL og se kæden
- Nulstil .htaccess/Nginx til standardstien
- Synkroniser WP_HOME/WP_SITEURL (om nødvendigt via WP-CLI)
- Kun én instans håndhæver https (server foretrækkes)
- Deaktiver plugins/tema, aktiver trin for trin
- Sæt proxy-header korrekt, tjek is_ssl()
- Tøm objekt/side/kant-cache
- Tjek logfiler: debug.log, access/error.log
- Særlige funktioner: Multisite, Woo, sprog, Hide-Login
Fejlmønstre ud over klassiske loops
Ikke alle 301/302 er et rigtigt loop - men Fejldirigering også omkostninger. En 301 til 404 signalerer til søgemaskinerne, at "denne ressource er her for evigt", men leverer tomhed. Eller en 302 i stedet for 301 forhindrer en permanent konsolidering af signaler. Jeg holder kæden på maksimalt et eller to niveauer, sætter 301 til permanente, 302 til midlertidige tilfælde og undgår tab af forespørgselsstrenge ved at sende QSA-flag eller args korrekt.
Stabile implementeringer og dokumentation
For at forhindre loops i at opstå i første omgang dokumenterer jeg hver eneste regelHvem router hvad til hvor - og hvorfor? Jeg bruger et staging-miljø, spiller regelændringer igennem der, logger overskrifter og tidspunkter og distribuerer derefter identiske server- og plugin-indstillinger i produktionen. En kort kontrol efter udrulning (startside, login, checkout, sprog) forhindrer fejl.
Konklusion i korte træk
Jeg udgiver en Forwarding loop Systematisk: Tjek cookies, nulstil .htaccess til standard, tilpas WP-URL'er, indstil SSL korrekt, isoler plugins/tema og lever serverheaders korrekt. Disse trin afslutter normalt løkken på kort tid. Derefter sikrer jeg installationen, dokumenterer omdirigeringer og holder opdateringer ajour. På den måde forbliver login tilgængeligt, besøgende lander på de rigtige sider, og søgemaskinerne crawler uden at miste tid. Med en struktureret tilgang undgår man gentagelser - og sparer nerver.
