Egy weboldalon a /szolgaltatas, a /szolgaltatas/ és a /Szolgaltatas/ elsőre ugyanannak tűnik. A böngésző mindhármat megnyitja, a látogató ugyanazt a tartalmat látja. A keresőmotor viszont három külön címet lát, és ha mindhárom 200-as válaszkóddal tölt be, el kell döntenie, melyiket tekinti az igazinak. Ez a cikk végigviszi, honnan ered a probléma, hogyan találod meg a saját oldaladon, és hogyan javítod úgy, hogy közben ne ronts el mást.
A szövegben jelölöm, mi hivatalosan igazolt (Google-dokumentáció, szabvány), mi saját tapasztalat (amit oldalak átvizsgálásakor rendszeresen látunk), és mi szakmai feltételezés (logikus következtetés, de nincs rá hivatalos megerősítés).
Miért kezeli a Google külön oldalként a perjeles és a perjel nélküli URL-t?
Röviden: mert technikailag két különböző címről van szó, és a szerver mindkettőre adhat eltérő választ. A Google nem feltételezi, hogy a kettő azonos, ezt neked kell egyértelművé tenned.
Hivatalosan igazolt. A Google Search Central blogja már 2010-ben leírta, hogy a https://example.hu/hal és a https://example.hu/hal/ két külön URL, amelyek akár eltérő tartalmat is szolgáltathatnak. Egyetlen kivétel van, a domain gyökere. A https://example.hu és a https://example.hu/ ugyanaz, mert a böngésző a perjelet mindenképp hozzáteszi.
A perjel régen jelentést hordozott. A perjeles cím egy könyvtárra utalt, a perjel nélküli egy fájlra. Ma a legtöbb tartalomkezelő ezt már nem így használja, de a keresőmotor a címet továbbra is karakterről karakterre hasonlítja össze.
Önmagában nem az a baj, hogy két változat létezik. A baj az, ha mindkettő 200-as kóddal, ugyanazzal a tartalommal válaszol. Ilyenkor a Google maga választ kanonikus változatot, a külső és belső linkek jelei megoszlanak, a feltérképezési keret egy részét pedig felesleges másolatokra költi.
Számít-e a kis- és nagybetű az URL-ben?
Röviden: a domainnévben nem, az útvonalban igen. A /Szolgaltatas/ és a /szolgaltatas/ két külön URL.
Hivatalosan igazolt. Az URI-szintaxist leíró RFC 3986 szabvány szerint a séma (https) és a hosztnév kis- és nagybetűtől független, az útvonal viszont érzékeny rá. Ezért a WWW.Example.hu ugyanaz, mint a www.example.hu, a /Rolunk/ viszont nem ugyanaz, mint a /rolunk/.
Az, hogy a szerver erre hogyan reagál, a környezettől függ. Linuxos Apache-on alapesetben a nagybetűs fájlnév egy másik fájlt jelent, Windowsos IIS-en jellemzően ugyanazt. Adatbázisból kiszolgált oldalaknál (például WordPressnél) az adatbázis összehasonlítási szabálya is beleszól.
Saját tapasztalat. Nagybetűs URL szinte soha nem a tartalomkezelőből keletkezik, hanem kézzel írt linkből. Tipikus források a hírlevélbe, nyomtatott anyagra vagy QR-kódba kézzel bemásolt cím, egy régi oldalról átvett menüpont, illetve egy partner, aki fejből írta be a linket.
Hogyan derül ki, hogy az oldaladon ilyen duplikáció van?
Röviden: kézzel lekéred a változatokat, majd egy crawlerrel és a Search Console-lal megnézed, melyik változat kap 200-as választ, és melyiket indexelte a Google.
1. Gyorsteszt a parancssorban
Válassz ki egy fontos aloldalt, és kérd le a változatait. A curl -I csak a fejlécet mutatja, ebből látszik a válaszkód és az átirányítás célja.
curl -I https://www.example.hu/szolgaltatascurl -I https://www.example.hu/szolgaltatas/curl -I https://www.example.hu/Szolgaltatas/
Az egészséges eredmény az, hogy egyetlen változat ad 200-at, a többi pedig egy lépésben 301-gyel arra mutat. Ha kettő vagy több ad 200-at, megvan a duplikáció. Ha 302-t látsz, az ideiglenes átirányítás, amit a Google kevésbé erős jelnek vesz. Ha több egymás utáni átirányítást látsz (például http, aztán https, aztán www, aztán perjel), az lánc, amit érdemes egy lépésre rövidíteni.
2. Feltérképezés crawlerrel
Egy asztali crawler (például a Screaming Frog SEO Spider vagy hasonló eszköz) végigjárja a belső linkeket, és minden talált URL-t listáz. Ebben a sorrendben érdemes nézni:
- Nagybetűs URL-ek. Az URL-listában szűrj a nagybetűt tartalmazó címekre. Ha van ilyen 200-as kóddal, nézd meg a hivatkozó oldalait, így kiderül, honnan jön a hibás link.
- Perjel-következetlenség. Exportáld az URL-eket, és nézd meg, van-e olyan útvonal, amely perjellel és anélkül is szerepel. Táblázatkezelőben a záró perjel levágása után a duplikátumok szűrése gyorsan megmutatja.
- Belső linkek átirányításra. Ha a belső linkek egy része 301-es címre mutat, a menü vagy a tartalom a nem kanonikus változatot használja.
- Canonical-ellenőrzés. Nézd meg, hogy a canonical címke pontosan a 200-as, végleges változatra mutat-e, perjellel együtt.
Érdemes a crawlert úgy is lefuttatni, hogy a sitemap URL-jeit is beolvassa. Így kiderül, ha a sitemap az egyik változatot tartalmazza, a belső linkek pedig a másikat.
3. A Search Console jelzései
Hivatalosan igazolt. A Search Console oldalindexelési jelentése több olyan kategóriát is mutat, amelyek ilyen duplikációra utalhatnak:
- Duplikált oldal, a felhasználó nem jelölt ki kanonikus oldalt
- Duplikált oldal, a Google a felhasználótól eltérő kanonikus oldalt választott
- Alternatív oldal megfelelő kanonikus címkével
- Átirányítással rendelkező oldal
Kattints bele a kategóriákba, és nézd meg a példa-URL-eket. Ha perjeles és perjel nélküli vagy kis- és nagybetűs párokat látsz, ott a gond. Az URL-ellenőrzés eszköz egy adott címnél megmutatja a felhasználó által megadott és a Google által választott kanonikus URL-t is. Ha a kettő eltér, a Google nem fogadta el a jelzésedet.
A teljesítményjelentésben az Oldalak fülön is érdemes keresni. Ha ugyanaz a tartalom két címen is gyűjt megjelenéseket, a jelek valószínűleg megoszlanak.
Hogyan javítsd 301-es átirányítással, canonicallal és belső linkekkel?
Röviden: döntsd el, melyik a végleges forma, minden más változatot egy lépésben 301-gyel irányíts rá, tegyél önhivatkozó canonicalt a végleges oldalra, és javítsd ki a belső linkeket, hogy eleve a jó címre mutassanak.
1. Döntsd el a végleges formát
A Google szempontjából mindegy, hogy perjellel vagy anélkül dolgozol. A következetesség számít. A gyakorlatban azt érdemes megtartani, amelyiket a tartalomkezelő alapból generál, és amelyik a legtöbb külső linket gyűjtötte. Kisbetűs URL-eket érdemes használni, ez a legkevésbé hibaérzékeny.
2. 301-es átirányítás
Hivatalosan igazolt. A Google a tartós átirányítást (301 vagy 308) erős kanonikus jelnek tekinti, erősebbnek a canonical címkénél. Egyetlen lépésben irányíts át, és a régi változat a végleges címre mutasson, ne egy közbülső címre.
3. Önhivatkozó canonical
A végleges oldal fejlécében legyen egy canonical címke, amely abszolút URL-lel önmagára mutat, a választott perjel-formával. Ez akkor is segít, ha valaki paraméterrel vagy egy el nem kapott változattal érkezik. Hivatalosan igazolt, hogy a canonical javaslat, nem utasítás. Ha a belső linkek, a sitemap és az átirányítások ellentmondanak neki, a Google másik változatot választhat.
4. Belső linkek és sitemap
Az átirányítás csak tűzoltás, ha a menü, a lábléc és a cikkek továbbra is a rossz változatra linkelnek. Javítsd ki a belső linkeket a crawler listája alapján, és ellenőrizd, hogy az XML-sitemap kizárólag végleges, 200-as címeket tartalmaz. Saját tapasztalat: a legtöbb fennmaradó hibás link a szövegtörzsbe kézzel beírt, abszolút címekből jön, nem a menüből.
Mi a WordPress alapértelmezett viselkedése?
Röviden: a WordPress a permalink-beállításhoz igazítja a perjelet, és a másik változatot jellemzően 301-gyel átirányítja. A kis- és nagybetűs eltéréseket nem minden esetben kezeli ilyen egyértelműen.
Hivatalosan igazolt. A WordPress magjában a redirect_canonical() függvény felel azért, hogy a nem kanonikus címekről a kanonikusra irányítson. Ha a permalink-szerkezet perjellel végződik (például /%postname%/), a perjel nélküli kérést a perjeles változatra irányítja, ha perjel nélkül végződik, akkor fordítva. Az új bejegyzések és oldalak slugját a WordPress alapból kisbetűsíti.
Saját tapasztalat. Nagybetűs útvonalnál a viselkedés oldalanként eltérhet. Előfordul, hogy a /Szolgaltatas/ átirányít, és olyan is, hogy 200-as kóddal ugyanazt az oldalt adja vissza. Ebbe a téma, a bővítmények, a gyorsítótár és az adatbázis összehasonlítási szabálya is beleszólhat. Ezért ne feltételezd, hanem teszteld a fenti curl parancsokkal.
Tipikus WordPress-csapdák még ezek.
- A permalink-szerkezet utólagos átállítása, ami után a régi belső linkek mind átirányításra mutatnak.
- SEO-bővítmény, amely a canonicalt másik formában írja ki, mint ahogy az oldal valójában elérhető.
- Oldalgyorsító bővítmény, amely a perjel nélküli változatot is gyorsítótárazza, és átirányítás helyett 200-zal szolgálja ki.
Mit ronthat el egy rosszul megírt .htaccess-szabály?
Röviden: átirányítási hurkot okozhat, eltörheti a fájlokat és az admin felületet, láncot hozhat létre, vagy ideiglenes átirányítást adhat tartós helyett.
A leggyakoribb hibák, amelyeket saját tapasztalatból rendszeresen látunk:
- Hurok. A .htaccess levágja a perjelet, a WordPress visszateszi. A böngésző néhány kör után hibát jelez, a crawler pedig átirányítási hibát.
- Fájlokra is ráhúzott szabály. A
stilus.cssvagy alogo.pngvégére is perjelet tesz, így a stíluslap és a képek nem töltődnek be. - Admin és API. A szabály a
/wp-adminés a/wp-jsonkéréseket is átirányítja, ami a szerkesztőt vagy egyes űrlapokat is eltörheti. Átirányításnál a POST-kérés adatai ráadásul elveszhetnek. - Rossz sorrend. A szabály a WordPress saját blokkja után áll, így soha nem fut le.
- R=302. A
[R]jelző önmagában 302-t ad, a tartós átirányításhoz[R=301,L]kell.
Ha perjel nélküli permalinkkel dolgozol, és mégis szerver szintű szabályt szeretnél a perjel hozzáadására, egy óvatosabb minta így néz ki. A WordPress blokkja (# BEGIN WordPress) elé kerül, és csak akkor szükséges, ha a WordPress maga nem kezeli a kérdést.
RewriteEngine On
RewriteCond %{REQUEST_METHOD} =GET
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_URI} !^/(wp-admin|wp-json|wp-content|wp-includes)
RewriteCond %{REQUEST_URI} !/$
RewriteCond %{REQUEST_URI} !\.[a-zA-Z0-9]{2,5}$
RewriteRule ^(.*)$ https://www.example.hu/$1/ [R=301,L]
A kisbetűsítésre a .htaccess önmagában nem alkalmas. Hivatalosan igazolt (Apache mod_rewrite dokumentáció), hogy a RewriteMap csak a szerver vagy a virtuális hoszt konfigurációjában adható meg, .htaccess-ben nem. Ha van hozzáférésed a szerverkonfigurációhoz, ott a RewriteMap lc int:tolower definícióval és egy nagybetűre szűrő feltétellel megoldható. Megosztott tárhelyen inkább egy átirányítás-kezelő bővítmény vagy egyenként felvett 301-es szabályok a járható út.
Szakmai feltételezés. Kis oldalnál, ahol csak néhány nagybetűs link kering, egyedi átirányítások felvétele és a forráslinkek kijavítása biztonságosabb, mint egy általános kisbetűsítő szabály. Utóbbi olyan címeket is érinthet (például kis- és nagybetűre érzékeny letöltési útvonalakat), amelyekre nem gondoltál.
Mennyi idő alatt rendeződik a helyzet a javítás után?
Röviden: ez nem előre megmondható, attól függ, milyen gyakran térképezi fel a Google az érintett oldalakat.
Szakmai feltételezés. A gyakran látogatott oldalakon az átirányítás hamarabb érvényesül, a ritkán feltérképezett aloldalakon lassabban. Az URL-ellenőrzés eszközzel kérheted egy-egy fontos oldal újbóli feltérképezését, és a sitemap újraküldése is segítheti a folyamatot. A javítás nem garantál helyezésjavulást. Annyit tesz, hogy a jelek egy címre kerülnek, és a Google nem a te helyetted választ.
Milyen ellenőrzőlistát futtass le migráció után?
Röviden: az alábbi lista a domainváltás, tárhelycsere, téma- vagy tartalomkezelő-váltás után is lefuttatható, mert ilyenkor a régi szabályok gyakran nem kerülnek át.
- Öt-tíz fontos aloldalnál kérd le a perjeles, perjel nélküli és nagybetűs változatot
curl -Iparanccsal. Csak egy adjon 200-at. - Ellenőrizd, hogy minden átirányítás 301 (vagy 308), és egy lépésben ér célba, lánc nélkül.
- Nézd meg, hogy a http, https, www és nem www változatok is egyetlen végleges hosztra mutatnak.
- Futtass teljes crawlt, és szűrj a nagybetűs URL-ekre, az átirányításra mutató belső linkekre és a 404-ekre.
- Ellenőrizd, hogy a canonical minden oldalon abszolút URL, önmagára mutat, és egyezik a választott perjel-formával.
- Nézd át az XML-sitemapet, hogy csak végleges, 200-as címek vannak benne.
- Teszteld, hogy a CSS, a képek, az admin felület és az űrlapok működnek, vagyis az átirányítási szabály nem ért hozzájuk.
- A Search Console-ban küldd be újra a sitemapet, és néhány hétig kövesd az oldalindexelési jelentés duplikációs kategóriáit.
- Az URL-ellenőrzés eszközzel nézd meg a legfontosabb oldalak Google által választott kanonikus URL-jét.
Ha a lista minden pontja rendben van, az oldal egyértelmű jeleket küld a keresőmotoroknak és a válaszmotoroknak is arról, melyik cím az igazi. Az AI-alapú keresők is URL-szinten hivatkoznak forrásra, ezért az egységes cím a hivatkozások tisztaságát is segítheti (ez utóbbi szakmai feltételezés).
Források és további olvasnivalók
- Google Search Central Blog, To slash or not to slash (2010)
- Google Search Central, Duplikált URL-ek összevonása (Consolidate duplicate URLs)
- Google Search Central, Átirányítások és a Google Kereső
- Search Console Súgó, Oldalindexelési jelentés
- Search Console Súgó, URL-ellenőrzés eszköz
- IETF RFC 3986, Uniform Resource Identifier (URI) Generic Syntax
- Apache HTTP Server dokumentáció, mod_rewrite és RewriteMap
- WordPress Developer Resources, redirect_canonical()
- Az URL útvonala kis- és nagybetű-érzékeny, és a záró perjel is két külön címet jelent, csak a domain gyökerénél nincs különbség.
- A duplikációt egy crawler 200-as válaszkódjai és a Search Console oldalindexelési jelentése együtt mutatja meg a legmegbízhatóbban.
- A javítás három része együtt működik jól: egyetlen lépéses 301-es átirányítás, önhivatkozó canonical és a belső linkek kijavítása.
- A WordPress alapból a permalink-beállításhoz igazítja a perjelet, ezért egy ellentétes .htaccess-szabály könnyen átirányítási hurkot okoz.
- Migráció után ugyanazt a rövid ellenőrzőlistát érdemes lefuttatni, mert a régi szabályok gyakran nem kerülnek át az új szerverre.
Gyakori kérdések
Melyik a jobb, a perjeles vagy a perjel nélküli URL?
A Google szempontjából egyik sem jobb, a következetesség számít. Azt érdemes megtartani, amelyiket a tartalomkezelőd alapból generál, a másikat pedig egy lépésben 301-gyel átirányítani rá.
Elég csak canonical címkét tenni az oldalra átirányítás nélkül?
Segíthet, de a canonical csak javaslat a Google számára. A tartós 301-es átirányítás erősebb jel, ezért ahol lehet, átirányítással és önhivatkozó canonicallal együtt érdemes dolgozni.
A domainnévben is számít a kis- és nagybetű?
Nem. Az RFC 3986 szabvány szerint a hosztnév kis- és nagybetűtől független, csak az útvonal érzékeny rá, így a /Rolunk/ és a /rolunk/ két külön URL.
Hogyan látom a Search Console-ban, melyik változatot választotta a Google?
Az URL-ellenőrzés eszköz egy adott címnél megmutatja a felhasználó által megadott és a Google által választott kanonikus URL-t. Ha a kettő eltér, a Google nem fogadta el a jelzésedet.
Tudok kisbetűsítő átirányítást írni .htaccess-ben?
Önmagában nem, mert a RewriteMap csak a szerver vagy a virtuális hoszt konfigurációjában adható meg. Megosztott tárhelyen egyedi 301-es szabályok vagy átirányítás-kezelő bővítmény a járható út.
Garantálja a javítás, hogy jobb helyezést kapok?
Nem garantálja. A javítás annyit ér el, hogy a jelek egy címre kerülnek, és nem a Google választ helyetted. Ez jó eséllyel tisztább indexelést hoz, de a helyezés sok más tényezőtől is függ.
Források és további olvasnivalók
Ezen az oldalon a hivatalosan igazolt információt elsődleges forrásokból építjük fel; a saját tapasztalatot és a szakmai becslést mindig külön jelöljük a szövegben.