301 vs 302 átirányítás

SEO

A 301 az egyetlen tiszta módja annak, hogy egy régi cím értékét átvidd egy újra. Rossz kóddal a régi URL marad a találati oldalon, sokszor már törölt tartalommal. Egy domain-csere vagy HTTPS-váltás után ez érzékeny forgalomvesztés. A domain-átirányítás és a HTTPS és TLS témakör szinte mindig ezen a ponton bukik el.

Sebesség és élmény

Minden ugrás egy plusz körút a szerverhez. Mobilon egy háromelemű lánc több száz ezredmásodpercet tesz a betöltésre. A felhasználó ebből csak a lassulást érzékeli.

AI-értelmezhetőség

A generatív keresők forrásként hivatkoznak URL-ekre. Ha a hivatkozott cím ideiglenes átirányítás mögött ül, a forrás is bizonytalan lesz. Egyszerű, végleges cím mögött stabil a tartalom.

Üzleti következmény

A kampány-URL-ek és a régi termékoldalak évekig élnek e-mailekben és külső linkekben. Egy jól beállított 301 ezt a forgalmat a pénztárig viszi. Egy 404 elveszíti.

Minden olyan oldalra vonatkozik, ahol valaha változott egy URL. Tipikus esetek:

• domain- vagy márkanévcsere
• HTTP-ről HTTPS-re váltás
• www és nem www közti egységesítés
• kategória- vagy terméknév módosítása
• webshop-migráció másik rendszerbe

KKV-oldalaknál gyakran csak néhány szabályról van szó. Webshopoknál több száz vagy ezer kivezetett termék sorsáról dönt ugyanez a kód.

Nem ide tartozik a staging és a fejlesztői környezet. Ott nem átirányítani kell, hanem jelszóval vagy noindex, meta robots és X-Robots-Tag jelzéssel kizárni a nyilvánosságból. A bejelentkezés utáni átdobás vagy egy A/B teszt viszont valóban ideiglenes, ott a 302 a helyes válasz.

1. Nyisd meg a böngésző devtools Network panelét. Kapcsold be a Preserve log és a Disable cache opciót, majd töltsd be a régi URL-t. A Status oszlopban minden ugrás külön sorban látszik.
2. Parancssorból gyorsabb: curl -sIL <url>. A válaszban nézd a HTTP/ sorokat és a location fejléceket.
3. A Search Console URL-ellenőrzés funkciója megmutatja, hogy a Google szerint a cím átirányítás-e, és mit tekint kanonikusnak.
4. Nézd át a sitemapot: abban csak 200-as végső URL-ek szerepeljenek.
5. Kattints végig a menü és a lábléc fontosabb linkjein. A belső linkek ne átirányításokra mutassanak.

Jó jel

• egyetlen ugrás, utána 200-as válasz
• végleges költözésnél 301 vagy 308
• a cél HTTPS-es, végleges cím

Rossz jel

• 302 egy régen lezárt költözésen
• két vagy több egymás utáni ugrás
• átirányítás nem kapcsolódó oldalra, például a főoldalra minden törölt termékről
• körkörös lánc, amit a böngésző hibával zár

Mit néz ebből a riport

Az audit betölti a megadott címet, és végigköveti az ugrásokat. Rögzíti a kódot, a lánc hosszát és a végső URL-t. Ha egy állandósult költözés 302-vel felel, vagy a lánc egynél hosszabb, azt hibaként jelzi.

WordPress

1. Telepíts egy átirányítás-kezelő bővítményt, vagy használd a SEO-bővítményed beépített moduljának ezt a funkcióját.
2. Új szabálynál mindig explicit válaszd a 301 Moved Permanently típust. Több bővítmény alapértelmezése 302.
3. Domain- vagy protokollváltásnál a szabályt inkább a szerveren tedd be, ne PHP-ben. Gyorsabb és megbízhatóbb.
4. Utána frissítsd a menük és a bannerek linkjeit is az új címre.

Shopify

1. Az adminban keresd az URL-átirányítások kezelőjét a navigációs beállítások alatt.
2. Add meg a régi és az új útvonalat. A rendszer ezeket véglegesként kezeli.
3. Tömeges migrációnál CSV-vel töltsd fel a szabályokat, majd mintavételesen ellenőrizd curl-lel.

Unas

1. Az adminban a SEO-beállítások környékén találod az átirányításokat kezelő felületet.
2. Vigyél fel régi-új cím párokat, és a mentés után ellenőrizd a tényleges státuszkódot.
3. Termék kivezetésekor a legközelebbi kategóriára irányíts, ne a főoldalra.

Shoprenter

1. Keresd az adminban az átirányítás-kezelő modult a SEO-hoz tartozó menüpontok között.
2. Rendszerváltás után exportáld a régi URL-listát, és párosítsd az újakhoz.
3. A régi rendszer sitemapjából dolgozz, így a valóban létezett címek kerülnek be.

Egyedi fejlesztés

• Nginx: return 301 https://uj-cim.hu$request_uri; a régi szerverblokkban.
• Apache: Redirect 301 /regi /uj, vagy RewriteRule ... [R=301,L].
• Laravel: Route::permanentRedirect() ad 301-et, a Route::redirect() alapból 302-t.
• Több szabálynál rendezd a láncot: a régi domain rögtön a végleges HTTPS-es célra mutasson.
• Ha él HSTS (HTTP Strict Transport Security), a HTTP-ről HTTPS-re ugrás továbbra is legyen a helyén az első látogatóknak.

• Végleges költözés 302-vel, mert az eszköz alapértelmezése ez volt: a régi URL így benn ragad az indexben.
• Átirányítási lánc: HTTP, majd www, majd új útvonal, három körútban. Minden ugrás idő, és a botok nem követik korlátlanul.
• Minden törölt termék a főoldalra dobva: a kereső ezt gyakran soft 404-ként kezeli, a vásárló pedig elveszíti a fonalat.
• A belső linkek a régi címen maradnak: az átirányítás elfedi a hibát, de minden kattintás feleslegesen kerül egy kört.
• Az átirányított URL ott marad a sitemapban: ellentmondó jelzés, a magyar KKV-oldalak többségén ez a migráció után hetekig így él.
• POST-os űrlap 302-vel átirányítva: az adat elveszhet, itt 307 vagy 308 a helyes megoldás.
• Ideiglenesnek szánt szabály örökre bent marad: senki nem veszi ki, és évekig ideiglenes állapotot jelez a keresőknek.

Láncot így nézel meg parancssorból:

curl -sIL https://pelda.hu/regi-termek | grep -Ei '^(HTTP|location)'

# HTTP/1.1 301
# location: https://www.pelda.hu/regi-termek
# HTTP/2 301
# location: https://www.pelda.hu/uj-termek
# HTTP/2 200

Itt két ugrás van, pedig egy is elég lenne. A helyes cél rögtön a https://www.pelda.hu/uj-termek.

Nginxben egy szerverblokk viszi a teljes régi domaint az újra:

server {
    listen 443 ssl;
    server_name pelda.hu;
    return 301 https://www.pelda.hu$request_uri;
}

A $request_uri megőrzi az útvonalat és a query stringet. Enélkül mindenki a főoldalon kötne ki.