Egy átnevezett oldalnál a régi címnek a megfelelő új tartalomra kell vezetnie. Több egymást követő átalakítás után azonban a régi cím egy köztes címre, az pedig újabb köztes címre mutathat. A látogató így több választ vár végig, mielőtt eléri a tartalmat.
A 301-es átirányítás generátora segíthet a szabály előállításában, de a kész szabályt az adott szerver környezetében tesztelni kell. Egy formailag helyes sor is okozhat hibát, ha ütközik egy másik átirányítással. Az alábbi útvonalak kitalált példák, az olvasó webhelyén nincs igazolt hiba.
Három ugrás egyetlen cél helyett
Tegyük fel, hogy a régi A cím B-re irányít, B C-re, C pedig D-re. Az A, B és C válasz átirányítás, a D címen érkezik meg a tényleges oldal. Ez három átirányítás és négy HTTP-válasz a kiindulástól számítva.
Ha mindhárom régi címhez ugyanaz a végleges D tartalom tartozik, külön-külön közvetlenül D-re mutathatnak. Az A cím felől ekkor egyetlen átirányítás és egy tartalmi válasz marad. A régi B és C címeket is kezelni kell, mert külső hivatkozások továbbra is érkezhetnek rájuk.
Ha a szemléltető mérésben egy átirányítás válaszára 120 ms jut, a három köztes válasz 360 ms, az egyetlen 120 ms. A különbség 240 ms. Ez saját egyszerűsített időmodell, nem általános gyorsulási ígéret; hálózat, gyorsítótár és kiszolgálás szerint más eredmény adódhat.
A hurok felismerése
A hurok legegyszerűbb alakja A → B → A. Ilyenkor nem érkezünk meg egy végső tartalmi oldalra. Hasonló probléma lehet, ha az egyik rendszer a www nélküli címet www-sre módosítja, a másik szabály pedig visszafordítja.
A teszt során jegyezd fel az összes köztes címet. Ha ugyanaz a teljes URL ismét megjelenik, a bejárt út körbeért. Ne pusztán az ugrások számát növeld a kliensben: a hurkot okozó szabályok kapcsolatát kell kijavítani.
Egy egyszerű előellenőrző táblázatban a forráscím, a célcím és az elvárt végállapot külön oszlop. A saját magára mutató sor és a több címen át visszaérő út már közzététel előtt észrevehető.
Státuszkód és végleges tartalom
A 301-es válasz tartós költözést jelez, célját a Location fejléc adja meg. A Google a tartós átirányítást kanonizálási jelzésként használhatja. Átmeneti helyzethez más átirányítási típus lehet megfelelő; a választás az alkalmazás működésétől is függ.
Űrlapok és API-k POST kéréseinél a HTTP-metódus megőrzését külön kell vizsgálni. A 301-es kezelés során a kliens GET-re válthat, míg a 308-as kód a metódus megőrzésére szolgál. Ezt a weboldalak egyszerű címcseréjéből nem szabad automatikusan más műveletekre kiterjeszteni.
A végső 200-as válasz sem elegendő önmagában. Nyisd meg a D címet, és ellenőrizd, hogy valóban a régi oldalhoz tartozó információt adja. Egy termékoldal általános főoldalra küldése megőrizheti a technikai elérhetőséget, miközben a látogatói feladat elvész.
Közzétételi próba
A módosítás előtt mentsd a meglévő szabályokat. Teszteld a régi címet, a végső címet, a köztes címeket és néhány olyan útvonalat, amelynek változatlanul kell működnie. Vizsgáld meg a paraméterek és a záró perjel kezelését is, de csak a szükséges körben módosíts.
Az URL-elemző a cím részeinek megértésében segít. A hosztnév, útvonal és lekérdezési rész eltérő szerepet kap, ezért egy általános szövegcserével könnyen túl széles szabály készülhet.
Gyakori kérdések
Minden köztes címet törölhetek?
A rájuk érkező kérések kezelését meg kell őrizni, amíg szükséges. A lánc rövidítése a végső cél közvetlen beállítását jelenti.
Egy 301-es kód garantálja a helyezés megőrzését?
Nem ad ilyen garanciát. A tartalom, a cél megfelelősége és a kereső feldolgozása is számít.
Elég a böngésző címsorát figyelni?
A végcím mellett a köztes válaszokat és státuszokat is ellenőrizni kell. A gyorsítótár miatt egy korábbi eredmény megtévesztő lehet.