Ellenőrizze a pontos URL-t egy olyan eszközzel, amely minden HTTP-lépést megjelenít. Derítse ki, melyik réteg ad vissza 404-et vagy Location fejlécet. WordPress-útválasztásnál ellenőrizze a slug létezését, a típusütközést és a rewrite szabályokat; átirányítási hurok esetén egységesítse a HTTPS-t, a hostot és a perjelet a proxy, a szerver és a WordPress beállításai között.
A WordPress 404-es hibája jelenthet hiányzó tartalmat, nem frissített rewrite szabályokat, slug-ütközést, szerverhibát vagy olyan kérést, amely el sem jutott a WordPressig. Átirányítási hurok pedig akkor keletkezik, amikor két réteg eltérő hostot, protokollt, perjelet vagy nyelvet kényszerít ki. A böngésző ugyanazt az általános hibát mutatja, pedig a javítás egészen más helyre tartozik.
A diagnosztika egyetlen kérést követ lépésről lépésre: DNS és proxy, HTTPS, webszerver, `.htaccess` vagy Nginx-szabályok, WordPress canonical redirect és bővítmények. A cél egyetlen preferált URL, és legfeljebb egy közvetlen átirányítás a régi változatról. A permalinkek véletlenszerű újramentése vagy egy újabb átirányító bővítmény hozzáadása átmenetileg megváltoztathatja a tünetet, de növeli a bizonytalanságot.
Rögzítse a pontos HTTP-útvonalat
Használjon curlt vagy a hálózati panelt, és rögzítse az eredeti URL-t, az állapotkódot, minden lépésnél a Location fejlécet és a végső választ. Teszteljen névtelenül, cache nélkül, majd egy szokásos böngészővel. Különböztesse meg a szerveroldali 404-et a WordPress-sablontól, a 200-as kóddal visszaadott soft 404-től és a biztonsági blokkolástól. Az időpont és a request ID segít megtalálni a bejegyzést a naplóban.
Próbálja ki a HTTP és HTTPS, a www-s változatot, a perjelet, a kisbetűket és a kampányparaméterek nélküli URL-t, de ne hozzon létre minden változathoz külön szabályt. Ha a CDN más választ ad, mint a közvetlen origin kapcsolat, a probléma az alkalmazás előtt vagy a gyorsítótárban van. A közvetlen origin tesztet csak jogosultsággal és a megfelelő Host fejléccel végezze.
Ellenőrizze a WordPress-útvonal létezését és ütközését
Az adminisztrációs felületen keresse meg a közzétett rekordot, annak slugját, állapotát, típusát és szülőjét. Ugyanazt az alapot használhatja egy oldal, egy tartalomtípus vagy egy taxonómia. A piszkozat vagy a privát rekord másként viselkedik egy anonim felhasználó számára. Ellenőrizze a nyelvi verziót is, valamint azt, hogy egy bővítmény nem ad-e hozzá azonos nevű endpointot.
A rewrite szabályok ellenőrzött módon frissíthetők a permalinkek mentésével vagy CLI-n keresztül, de ezt ne alkalmazza rendszeres tüneti kezelésként. Egy egyedi bővítmény csak aktiváláskor vagy szabálymódosításkor hajtson végre flusht, ne minden kérésnél. Ha a frissítés segített, keresse meg azt a komponenst, amely nem a megfelelő időben regisztrálta a szabályokat, vagy ismételten felülírja őket.
- A bejegyzés állapota és típusa
- Slug- vagy alapcím-ütközés
- Nyelvi és szülőoldali útvonal
- Rewrite szabály regisztrálása
Ossza fel az átirányítási rétegek felelősségét
A kanonikus hostot és a HTTPS-t ideális esetben egyetlen peremhálózati vagy szerveroldali rétegen kezelje, a proxyfejlécek figyelembevételével. A WordPressnek ismernie kell a helyes nyilvános sémát és címet. Ha a CDN zárja le a HTTPS-kapcsolatot, az origin azonban továbbra is HTTP-nek tekinti, az alkalmazás visszairányíthat. Megbízható proxyfejlécet csak ismert közvetítőtől fogadjon el.
Az SEO-bővítmény, az átirányítási bővítmény, a többnyelvű bővítmény és az egyedi kód mind módosíthatja a Location fejlécet. Készítsen leltárt, és minden kategóriához rendeljen felelőst: a hoszt/protokoll a szerverhez, a régi tartalmi URL-ek a migrációs térképhez, a nyelv a fordítási rendszerhez tartozzon. Egy szabálynak egy célja legyen. A láncokat úgy rövidítse le, hogy az első lépést a végső célra frissíti.
A régi és érvénytelen URL-eket jelentésük szerint kezelje
Ha a tartalom áthelyeződött, használjon tartós, közvetlen átirányítást a legközelebbi helyettesítőre. Ha soha nem létezett, vagy nincs helyettesítője, a megfelelő 404 a helyes megoldás. Ha mindent tömegesen a kezdőlapra irányít, az félrevezeti a felhasználót, és elrejti a hibás hivatkozásokat. Ideiglenes átirányítást csak valóban ideiglenes állapotnál használjon, megszüntetési tervvel.
Az egyedi 404-es oldalnak 404-es kódot kell visszaadnia, el kell magyaráznia a helyzetet, és navigációt vagy keresést kell felkínálnia. Nem tartalmaz néhány másodperc utáni automatikus átirányítást. Kövesse a leggyakoribb hibás útvonalakat, és javítsa a hivatkozás belső forrását. Rosszindulatú vagy véletlenszerű szkennelés esetén nem szükséges minden próbálkozásra szabályt létrehozni.
- 301 a tartós, releváns helyettesítéshez
- 302 csak ideiglenes állapothoz
- Valódi 404-es kód hamis átirányítás nélkül
- Belső hivatkozás javítása a forrásnál
Tesztelje a szabályokat telepítés előtt és után
A migrációs térképből készítsen automatikus tesztet a régi URL-lel, az elvárt állapottal és a végső céllal. Vegye bele a perjelet, a query stringet, a kódolt karaktereket és néhány nem létező címet. Stagingen más lehet a hoszt, ezért a szabályok nem küldhetik a látogatót fixen az éles környezetbe. A szerverkonfigurációt az újratöltés (reload) előtt validálja.
Telepítés után nézze végig a kiemelt címeket, figyelje a hurkokat, az 5xx hibákat és a 404-es hibák számának növekedését a naplókban. Csak a releváns CDN cache-t ürítse. A változtatásokat indoklással és dátummal dokumentálja, hogy a régi szabály ne térjen vissza a következő migráció során. Incidens esetén előbb őrizze meg bizonyítékként az eredeti átirányítási láncot, és csak ezután módosítsa a rétegeket.
Gyakori kérdések
Segít a permalinkek mentése WordPress 404 esetén?
Helyreállíthatja a rewrite szabályokat és igazolhatja ezt a réteget, de nem univerzális javítás. Ha a probléma ismételten jelentkezik, meg kell találni a slug-ütközést, a hibás regisztrációt vagy azt a szerverszabályt, amely az állapotot okozza.
Miért jelentkezik az ERR_TOO_MANY_REDIRECTS hiba?
Leggyakrabban két réteg nem ért egyet a HTTPS, a host, a perjel, a nyelv vagy a bejelentkezés kérdésében, és oda-vissza küldözgetik a kérést. Rögzítse a teljes láncot, és az első ütköző réteget módosítsa, ne vakon a cookie-kat.
Minden 404-es oldalt a kezdőlapra irányítsak át?
Nem. Csak azt a régi URL-t irányítsa át, amelynek van releváns helyettesítője. A nem létező címnek valódi 404-et kell visszaadnia hasznos navigációval. A tömeges átirányítás összezavarja az embereket, és megnehezíti a hibás hivatkozások felderítését.
Források és további olvasnivaló
Adam Antoni vyvíja weby, aplikácie a softvér na mieru. Prepája firemné systémy, automatizuje procesy a vytvára AI agentov. Pôsobí v Spišskej Novej Vsi a spolupracuje s firmami na celom Slovensku.
