Az internet, ahogyan ma ismerjük, egy hatalmas, összekapcsolt információs hálózat, amelynek működése alapvető fogalmakon nyugszik. Ezen alapvető elemek egyike az URL, azaz a Uniform Resource Locator. Gyakran egyszerűen csak webcímként emlegetjük, de valójában sokkal többről van szó, mint egy egyszerű azonosítóról. Az URL a web egyik legfontosabb építőköve, amely lehetővé teszi számunkra, hogy pontosan megtaláljuk és elérjük a digitális térben tárolt erőforrásokat, legyen szó weboldalakról, képekről, videókról, dokumentumokról vagy bármilyen más digitális fájlról.
Az URL egy szabványosított formátumú karaktersorozat, amely nem csupán egy adott erőforrás helyét azonosítja a hálózaton, hanem egyben meghatározza azt a mechanizmust is, amellyel az erőforrás elérhető. Ez a kettős funkció – az azonosítás és az elérés módjának meghatározása – teszi az URL-t elengedhetetlenné a web működéséhez. Gondoljunk rá úgy, mint egy könyvtári katalógus bejegyzésére, ahol nemcsak a könyv címe és szerzője van megadva, hanem az is, hogy hol található fizikailag a könyvtárban, és milyen módon juthatunk hozzá (pl. kölcsönözhető-e). Az URL esetében ez a „hol” és „hogyan” digitális környezetben valósul meg.
A web kezdeti időszakában, az 1990-es évek elején, az információk strukturálása és elérhetővé tétele jelentette a legnagyobb kihívást. Tim Berners-Lee, a World Wide Web atyja, felismerte, hogy szükség van egy egységes rendszerre az erőforrások azonosítására és lokalizálására. Ennek eredményeként született meg az URI (Uniform Resource Identifier) koncepciója, amelynek két fő alosztálya az URL és az URN (Uniform Resource Name). Míg az URN egy erőforrás nevét azonosítja függetlenül annak helyétől (pl. egy ISBN szám egy könyvhöz), addig az URL az erőforrás helyét adja meg, és egyben azt is, hogyan lehet hozzáférni. A mindennapi nyelvben az URL és a webcím kifejezések váltak általánossá, és a legtöbb esetben felcserélhetően használatosak.
Az URL pontos felépítésének megértése kulcsfontosságú nemcsak a webfejlesztők és rendszergazdák számára, hanem a tartalomkészítők és SEO szakemberek számára is. Egy jól strukturált, értelmes URL nem csupán technikai szempontból kifogástalan, de hozzájárul a jobb felhasználói élményhez, a keresőmotorok általi hatékonyabb indexeléshez, és végső soron a weboldal láthatóságához és sikeréhez. Ez a cikk részletesen bemutatja az URL definícióját, felépítését és a különböző komponensek jelentőségét, kitérve a SEO-ra és a felhasználói élményre gyakorolt hatásukra is.
Az URL alapvető felépítése és komponensei
Az URL egy sorozatnyi, egymástól meghatározott elválasztó karakterekkel (például kettőspont, perjel, kérdőjel, hashmark) elválasztott komponensből áll. Ezek a komponensek mindegyike specifikus információt hordoz, és együttesen biztosítják az erőforrás pontos azonosítását és elérhetőségét. Az általános URL szintaxis a következőképpen írható le:
scheme://user:password@host:port/path?query#fragment
Vizsgáljuk meg részletesen az egyes komponenseket, és azok jelentőségét a webes ökoszisztémában.
Protokoll (scheme)
Az URL első és talán legfontosabb része a protokoll, vagy más néven séma (scheme). Ez a rész határozza meg, hogy a kliens (például egy webböngésző) milyen kommunikációs protokollt használjon az erőforrás eléréséhez. A protokoll után általában egy kettőspont és két perjel (://
) következik, jelezve a protokoll rész végét és az autoritás rész kezdetét. A leggyakrabban használt protokollok a webes környezetben a HTTP és a HTTPS, de számos más protokoll is létezik, amelyek különböző célokra szolgálnak, és mindegyiknek megvan a maga specifikus felhasználási területe és jelentősége.
HTTP (Hypertext Transfer Protocol): Ez a protokoll volt a web eredeti alapja, és a mai napig a legelterjedtebb a weboldalak böngészéséhez. Kliens és szerver közötti kommunikációra szolgál, amely során a weboldalak, képek, videók és egyéb tartalmak átvitelre kerülnek. A HTTP egy állapotmentes protokoll, ami azt jelenti, hogy minden egyes kérés független az előzőtől, bár a sütik (cookies) segítségével a munkamenetek fenntarthatók. Bár széles körben elterjedt, a HTTP egyik jelentős hátránya, hogy az adatátvitel titkosítatlanul történik. Ez azt jelenti, hogy az adatok „nyíltan” utaznak a hálózaton, és potenciálisan lehallgathatók vagy módosíthatók rosszindulatú felek által. Ez komoly biztonsági kockázatokat rejt magában, különösen érzékeny adatok (pl. jelszavak, bankkártya adatok, személyes információk) továbbításakor.
HTTPS (Hypertext Transfer Protocol Secure): A HTTPS a HTTP biztonságos változata. Kiegészül az SSL/TLS (Secure Sockets Layer/Transport Layer Security) protokollal, amely titkosítja a kliens és a szerver közötti kommunikációt. Az SSL/TLS egy kriptográfiai protokoll, amely három alapvető biztonsági funkciót biztosít: titkosítás (az adatok olvashatatlanná tétele harmadik fél számára), adatintegritás (biztosítja, hogy az adatok ne módosuljanak az átvitel során) és hitelesítés (ellenőrzi a szerver identitását). Ez azt jelenti, hogy az adatokat titkosítva továbbítják, így azok nem olvashatók el harmadik fél számára, még akkor sem, ha azokat valahogyan elfogják. A HTTPS használata ma már iparági szabvány, és a keresőmotorok, különösen a Google, előnyben részesítik a HTTPS-t használó weboldalakat a rangsorolás során. Emellett a felhasználók is egyre inkább tudatában vannak a biztonságos kapcsolat fontosságának, és a modern böngészők (pl. Chrome, Firefox) vizuálisan is figyelmeztetnek, ha egy oldal nem HTTPS-t használ, ami negatívan befolyásolhatja a felhasználói bizalmat és az átkattintási arányt.
A HTTPS nem csupán egy technikai követelmény, hanem egy bizalmi jel is a felhasználók felé, ami alapvető a mai webes környezetben és a keresőmotorok rangsorolási szempontjai között.
A HTTP és HTTPS protokollok alaposabb megértése kulcsfontosságú minden webes szereplő számára. A HTTP a web alapja, a HTTPS pedig annak biztonságos és modern kiterjesztése. A titkosítási réteg biztosítja az adatok integritását és bizalmasságát, ami elengedhetetlen a mai online tranzakciókhoz és személyes adatok kezeléséhez. Egy weboldal átállítása HTTP-ről HTTPS-re összetett feladat lehet, amely magában foglalja az SSL/TLS tanúsítvány beszerzését és telepítését, a belső linkek frissítését, és a megfelelő átirányítások (301-es redirectek) beállítását, hogy a keresőmotorok és a felhasználók zökkenőmentesen megtalálják az új, biztonságos verziót. A migrációs folyamat során a Google Search Console-ban is jelezni kell a változást, hogy a Googlebot hatékonyan tudja feldolgozni az új URL-eket.
Egyéb protokollok: Bár a HTTP/HTTPS a leggyakoribb, számos más protokoll is létezik, amelyek specifikus erőforrások elérésére szolgálnak, és különböző hálózati szolgáltatásokhoz kapcsolódnak:
- FTP (File Transfer Protocol): Fájlok átvitelére szolgál számítógépek között egy kliens-szerver modellben. Bár a webböngészők képesek FTP erőforrásokat megjeleníteni, gyakrabban használnak dedikált FTP klienseket. Példa:
ftp://example.com/pub/file.zip
. - Mailto: E-mail címekhez kapcsolódik, és egy kattintással megnyitja a felhasználó alapértelmezett e-mail kliensét az előre beállított címzettel, tárggyal vagy akár üzenettesttel. Példa:
mailto:info@example.com?subject=Kérdés&body=Üdvözlöm!
. - File: Helyi fájlrendszerbeli erőforrásokra mutat, lehetővé téve a helyi fájlok böngészőben való megnyitását. Példa:
file:///C:/Users/User/Documents/document.pdf
(Windows) vagyfile:///home/user/document.pdf
(Linux). Ezeket az URL-eket általában csak helyi környezetben használják, nem a nyilvános weben. - Tel: Telefonszámokhoz kapcsolódik, és lehetővé teszi a közvetlen hívást a linkre kattintva mobil eszközökön, vagy a hívás kezdeményezését a számítógépen, ha van erre alkalmas szoftver. Példa:
tel:+36701234567
. - Data: Adatokat ágyaz be közvetlenül az URL-be, általában base64 kódolással. Képek, CSS vagy JavaScript adatok beágyazására használható a HTML-be, anélkül, hogy külön fájlként kellene hivatkozni rájuk. Ez csökkentheti a HTTP kérések számát, de növelheti a HTML fájl méretét. Példa:
data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUAAAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO9TXL0Y4OHwAAAABJRU5ErkJggg==
(egy apró, piros négyzet képe). - WebSocket (ws/wss): A WebSocket protokoll a kétirányú kommunikációt teszi lehetővé a kliens és a szerver között egyetlen, hosszú életű kapcsolaton keresztül, ami ideális valós idejű alkalmazásokhoz (pl. chat, online játékok). A
ws://
a titkosítatlan, awss://
a titkosított változat. Példa:wss://example.com/chat
.
Ezen protokollok mindegyike a maga módján járul hozzá az internet sokszínűségéhez és funkcionalitásához, lehetővé téve a különböző típusú erőforrások egységes azonosítását és elérését az URL rendszerén keresztül. A megfelelő protokoll kiválasztása és használata alapvető a webes alkalmazások és szolgáltatások hatékony és biztonságos működéséhez.
Autoritás (authority)
A protokoll után következik az autoritás rész, amely az erőforrást tároló szerver azonosítására szolgál. Ez a rész opcionális, de a webcímek túlnyomó többségében jelen van. Az autoritás rész tovább bontható felhasználói információra (userinfo), hosztra (host) és portra (port). Ezek az elemek együttesen határozzák meg, hogy melyik szerverhez kell kapcsolódni, és azon belül melyik szolgáltatáshoz.
Felhasználói információ (userinfo)
A felhasználói információ rész tartalmazhatja a felhasználónevet és jelszót, amelyeket a szerver hitelesítésére használnak. Formátuma felhasználónév:jelszó@
. Például: ftp://admin:password@ftp.example.com/
. Bár technikailag létezik ez a rész a szabványban, a modern webböngészők és biztonsági gyakorlatok miatt használata erősen ellenjavallt és sok böngésző már figyelmen kívül hagyja vagy biztonsági figyelmeztetést ad rá. Ennek oka, hogy a jelszó nyílt szövegként jelenik meg az URL-ben, ami komoly biztonsági kockázatot jelent, hiszen bárki, aki látja az URL-t (pl. böngésző előzmények, hálózati forgalom elemzése), hozzáférhet a hitelesítő adatokhoz. A hitelesítést ma már sokkal biztonságosabb módszerekkel, például OAuth, API kulcsok, JSON Web Tokens (JWT) vagy munkamenet-alapú hitelesítés segítségével végzik, amelyek nem teszik láthatóvá az érzékeny adatokat az URL-ben.
Hoszt (host)
A hoszt az autoritás rész legfontosabb eleme, amely az erőforrást szolgáltató szerver azonosítóját tartalmazza. Ez lehet egy domain név (pl. www.example.com
) vagy egy IP cím (pl. 192.168.1.1
IPv4 esetén, vagy [2001:0db8:85a3:0000:0000:8a2e:0370:7334]
IPv6 esetén, zárójelek között a kettőspontok miatt). A domain nevek az IP címek emberi olvasásra alkalmasabb megfelelői, amelyeket a DNS (Domain Name System) rendszer fordít le IP címekké, hogy a számítógépek megtalálhassák egymást a hálózaton. A DNS egy elosztott adatbázis-rendszer, amely a domain neveket IP címekre és fordítva fordítja, lényegében az internet „telefonkönyveként” funkcionál.
A domain nevek hierarchikus felépítésűek. A hierarchia tetején a gyökér domain (root domain) található, amelyet ponttal (.) jelölnek. Ezt követik a felső szintű domainek (TLD-k – Top-Level Domains). A TLD-k két fő kategóriába sorolhatók:
- gTLD-k (generic Top-Level Domains): Általános célú TLD-k, mint a
.com
(kereskedelmi),.org
(szervezetek),.net
(hálózatok),.info
(információs oldalak),.biz
(üzleti),.gov
(kormányzati),.edu
(oktatási), és az újabb, specifikusabb TLD-k, mint a.app
,.blog
,.shop
,.online
. - ccTLD-k (country code Top-Level Domains): Országkódos TLD-k, mint a
.hu
(Magyarország),.de
(Németország),.uk
(Egyesült Királyság). Ezek általában egy adott országra vagy földrajzi területre utalnak, és hasznosak a helyi SEO szempontjából.
A TLD-k után következik a második szintű domain (SLD – Second-Level Domain), ami általában a cég vagy márka neve (pl. example
a example.com
-ban). Ez az a rész, amit a legtöbb felhasználó regisztrál és egyedileg azonosítja a weboldalt. Az SLD előtt állhatnak aldomainek (subdomains), mint például a www
, blog
, shop
(pl. blog.example.com
). Az aldomainek lehetővé teszik a weboldalak logikai felosztását és szervezését anélkül, hogy új domain nevet kellene regisztrálni. Például egy blog, egy webshop vagy egy támogatási oldal is futhat aldomainen.
Az IP címek a hálózaton lévő eszközök egyedi numerikus azonosítói. Két fő típusuk van: IPv4 és IPv6. Az IPv4 címek négy, pontokkal elválasztott számból állnak (pl. 192.168.1.1
), és körülbelül 4,3 milliárd egyedi címet tudnak biztosítani, ami mára gyakorlatilag kimerült. Az IPv6 címek hexadecimális számokból álló, kettőspontokkal elválasztott csoportok (pl. 2001:0db8:85a3:0000:0000:8a2e:0370:7334
), és sokkal nagyobb címtartományt biztosítanak (körülbelül 3,4 x 10^38 címet), ami gyakorlatilag végtelen számú eszközt képes azonosítani. Habár az IP címek technikailag használhatók URL-ekben, a domain nevek sokkal inkább preferáltak a könnyebb megjegyezhetőség és az emberi olvashatóság miatt, valamint a domain nevek rugalmasabbak a szerverek áthelyezése vagy IP cím változása esetén, mivel a DNS rendszer kezeli a mögöttes IP címek frissítését.
A domain név és annak struktúrája jelentős hatással van a SEO-ra. Egy releváns és rövid domain név, jól megválasztott TLD-vel, hozzájárul a márkaépítéshez és a felhasználói bizalomhoz. Az aldomainek használata stratégiai döntés lehet a tartalom szervezése szempontjából, de fontos figyelembe venni, hogy a keresőmotorok bizonyos mértékig külön entitásként kezelhetik őket a fő domainhez képest. Ezért a domain és aldomain stratégia gondos tervezést igényel, különösen, ha az aldomainek jelentős, önálló tartalommal rendelkeznek, amelyet a fő domainhez képest eltérő célközönségnek szánnak.
Port
A port szám az autoritás rész utolsó opcionális eleme, amelyet kettőspont (:
) választ el a hoszttól. A port szám azt a specifikus „kaput” azonosítja a szerveren, amelyen keresztül a kommunikáció történik. Egy szerver több szolgáltatást is futtathat egyszerre, és minden szolgáltatás egy adott porton figyel a bejövő kérésekre. Például, a web szerverek alapértelmezett HTTP portja a 80-as, a HTTPS portja pedig a 443-as. Ha az URL-ben nincs megadva port szám, a böngésző az adott protokollhoz tartozó alapértelmezett portot használja (pl. 80-at HTTP-hez, 443-at HTTPS-hez). Ezért a legtöbb webcímben nem látunk port számot.
Például: http://example.com:8080/
ebben az esetben a szerver 8080-as portján futó szolgáltatáshoz próbál kapcsolódni. A port számok ritkán jelennek meg a nyilvános weboldalak URL-jeiben, mivel a legtöbb weboldal az alapértelmezett portokon keresztül érhető el. Főként webfejlesztés során, tesztkörnyezetekben, speciális hálózati konfigurációk esetén, vagy nem webes protokollok (pl. adatbázis-kapcsolatok) esetén találkozhatunk velük. Ezenkívül a portok kritikus szerepet játszanak a hálózati biztonságban, mivel a tűzfalak segítségével szabályozható, hogy mely portok legyenek nyitva a külső forgalom számára.
Útvonal (path)
Az útvonal (path) az URL azon része, amely az erőforrás pontos helyét írja le a szerveren belül, a domain név után. Ez a rész perjelekkel (/
) elválasztott könyvtár- és fájlnevek hierarchiáját tükrözi, hasonlóan egy fájlrendszerhez. Például, a https://www.example.com/blog/2023/cikk-cime.html
URL-ben a /blog/2023/cikk-cime.html
az útvonal. Az útvonal megmutatja a szervernek, hogy pontosan melyik fájlt vagy erőforrást kell kiszolgálnia a kérésre válaszul.
Az útvonalnak jelentős szerepe van a SEO-ban és a felhasználói élményben egyaránt. Egy jól strukturált és beszédes útvonal segít a keresőmotoroknak megérteni a tartalom hierarchiáját és témáját, valamint a felhasználóknak is könnyebbé teszi a navigációt és a tartalom relevanciájának megítélését. Ideális esetben az útvonal tartalmazza a fő kulcsszavakat, és logikusan épül fel, tükrözve a weboldal struktúráját, mintha egy hierarchikus könyvtárrendszert járnánk be.
Például, egy webshopban a /kategoria/alkategoria/termek-neve/
struktúra sokkal intuitívabb és SEO-barátabb, mint egy véletlenszerűen generált azonosítókat tartalmazó útvonal (pl. /p?id=12345
). A „slug” (az URL utolsó, általában kulcsszavakat tartalmazó része, mint a cikk-cime.html
) optimalizálása kulcsfontosságú. Javasolt a rövid, releváns, kötőjelekkel elválasztott szavak használata, ékezetes karakterek és speciális jelek kerülése (URL-kódolás nélkül), mivel ezek nehezebbé tehetik az URL megjegyezhetőségét és megosztását, ráadásul kódolva hosszú és olvashatatlan stringeket eredményezhetnek.
Az útvonal lehet relatív vagy abszolút. Az abszolút útvonal a gyökértől kezdődik (pl. /kategoria/oldal.html
), míg a relatív útvonal az aktuális oldalhoz képest adja meg a helyet (pl. oldal2.html
vagy ../oldal3.html
). Webfejlesztés során mindkettőnek megvan a maga helye, de a SEO szempontjából az abszolút URL-ek használata javasolt a belső linkek esetében, hogy elkerüljük az esetleges hibákat és a keresőmotorok félreértelmezését, valamint a link juice konzisztens átadását. A tiszta URL-ek, amelyek nem tartalmaznak felesleges számokat, speciális karaktereket vagy dátumokat, ha azok nem relevánsak a tartalom időbeliségéhez, sokkal preferáltabbak.
Lekérdezési karakterlánc (query string)
A lekérdezési karakterlánc (query string) az URL azon része, amely a kérdőjel (?
) után következik, és kulcs-érték párokat tartalmaz, amiket az ampersand (&
) karakter választ el egymástól. Ezek a paraméterek dinamikus információkat adnak át a szervernek, amelyek alapján a szerver személyre szabott tartalmat generálhat, vagy valamilyen műveletet hajthat végre, anélkül, hogy az URL alapvető útvonalát megváltoztatná. Például: https://www.example.com/kereses?q=seo+tanacsok&oldal=2&kategoria=blog
. Ebben az esetben a q
paraméter értéke seo+tanacsok
, az oldal
paraméter értéke 2
, és a kategoria
paraméter értéke blog
.
A lekérdezési karakterláncokat gyakran használják a webes alkalmazásokban a következő célokra:
- Keresési eredmények: A felhasználó által beírt keresési kifejezés átadása, amely alapján a szerver a releváns eredményeket jeleníti meg.
- Szűrők és rendezés: Termékek szűrése ár, méret, szín szerint egy webshopban, vagy rendezés relevancia, ár szerint. Ezek a paraméterek lehetővé teszik a felhasználók számára, hogy testreszabott nézetet kapjanak az adatokról.
- Lapozás: A jelenlegi oldal számának átadása egy hosszú listában vagy keresési eredmények között.
- Nyomkövetés (tracking): Például UTM paraméterek használata a Google Analyticsben a forrás, kampány, médium azonosítására (pl.
?utm_source=facebook&utm_medium=social&utm_campaign=nyari_akcio
). Ezek a paraméterek nem befolyásolják az oldal tartalmát, csupán a látogató forrását rögzítik az analitikai rendszerek számára. - Munkamenet azonosítók: Régebben gyakori volt a munkamenet azonosítók átadása az URL-ben (pl.
?sid=XYZ
), de ez ma már ritkább és biztonsági okokból ellenjavallt, mivel a munkamenet-azonosító kiszivároghat. Helyette a sütik használata preferált.
A lekérdezési karakterláncok kezelése különösen fontos a SEO szempontjából. A túl sok paraméter, vagy a paraméterek rendszertelen használata duplikált tartalomhoz vezethet, mivel a keresőmotorok különböző URL-eket láthatnak ugyanahhoz a tartalomhoz. Ez negatívan befolyásolhatja az indexelést és a rangsorolást, mivel a keresőmotorok nem tudják, melyik URL-t tekintsék az „eredetinek”, és szétaprózódhat a linkekből származó „erő”. A Google Search Console (korábbi nevén Google Webmaster Tools) lehetőséget biztosít a paraméterek kezelésére, jelezve a Google-nek, hogy mely paramétereket hagyja figyelmen kívül az indexelés során, vagy melyek változtatják meg jelentősen a tartalmat.
A kanonikus URL-ek (canonical URLs) használata elengedhetetlen a paraméteres URL-ek kezelésében. A <link rel="canonical" href="...">
tag segítségével jelezhetjük a keresőmotoroknak, hogy melyik az adott tartalom „preferált” vagy „eredeti” URL-je, még akkor is, ha több URL-en keresztül is elérhető. Ez segít konszolidálni a rangsorolási jeleket az egyetlen kanonikus URL-re, elkerülve a duplikált tartalommal járó problémákat. Az URL-paraméterek megfelelő kezelése kritikus a hatékony feltérképezés és indexelés szempontjából, különösen nagyméretű weboldalakon, ahol a feltérképezési költségvetés (crawl budget) optimalizálása kulcsfontosságú.
Töredék (fragment)
A töredék (fragment) az URL utolsó, opcionális része, amelyet a hashmark (#
) karakter választ el a lekérdezési karakterlánctól (vagy az útvonaltól, ha nincs lekérdezés). A töredék egy belső azonosító, amely egy adott pontra mutat az erőforráson belül. Például: https://www.example.com/oldal.html#szakasz-cime
. Ebben az esetben a böngésző betölti az oldal.html
-t, majd automatikusan a szakasz-cime
azonosítóval ellátott elemre görget. Ez az azonosító általában egy HTML elem id
attribútumának felel meg (pl. <h2 id="szakasz-cime">
).
A töredékek funkciói és jellemzői:
- Belső navigáció: Hosszú oldalakon belül a felhasználók gyorsan navigálhatnak a különböző szakaszok között (pl. tartalomjegyzék linkjei egy hosszú blogbejegyzésben). Ez jelentősen javítja a felhasználói élményt, hiszen a felhasználónak nem kell manuálisan görgetnie, hogy megtalálja a keresett információt.
- SPA-k (Single Page Applications): Modern webalkalmazásokban gyakran használják a böngésző előzményeinek és az oldal állapotának kezelésére anélkül, hogy az egész oldalt újra kellene tölteni. A JavaScript segítségével az URL hash része megváltoztatható, ami új tartalmat tölthet be az oldalon belül, miközben a böngésző előzményei is frissülnek, lehetővé téve a vissza/előre gombok működését.
- Keresőmotorok: Hagyományosan a keresőmotorok nem veszik figyelembe a töredék részt az indexelés során, mivel az kliens oldali funkció, és a szerverhez intézett kérés során a töredék rész nem kerül továbbításra. Ez azt jelenti, hogy a
https://example.com/page#section1
és ahttps://example.com/page#section2
URL-eket ugyanannak az oldalnak tekintik. Azonban a Google az utóbbi időben képes lehet bizonyos esetekben indexelni a fragmentumokkal ellátott URL-eket, különösen ha azok egyedi, görgethető tartalomra mutatnak, ami a felhasználó számára releváns lehet (pl. kiemelt részletek, „featured snippets” a keresési eredményekben, ahol a Google közvetlenül egy oldalon belüli szakaszra mutat). Ez a képesség azonban korlátozott, és nem helyettesíti a dedikált URL-eket.
Fontos megjegyezni, hogy bár a töredékek felhasználói élmény szempontjából hasznosak, SEO szempontjából óvatosan kell velük bánni, ha az adott szakasz önmagában is releváns keresési lekérdezésekre. Ebben az esetben érdemes lehet külön oldalt vagy aloldalt létrehozni, vagy a tartalom egyedi URL-en való elérhetőségét biztosítani más módon, például a hagyományos útvonal vagy lekérdezési paraméterek használatával, hogy a keresőmotorok teljes mértékben indexelhessék és rangsorolhassák az adott tartalmi egységet.
URL kódolás: miért és hogyan?
Az URL-ekben csak egy meghatározott karakterkészlet használható közvetlenül, minden más karaktert URL kódolni kell. Ez a folyamat más néven percent-encoding, mivel a kódolt karakterek egy százalékjellel (%
) kezdődnek, amit a karakter ASCII vagy UTF-8 kódjának hexadecimális értéke követ. Erre azért van szükség, mert az URL-ek bizonyos karaktereket (például perjel, kérdőjel, ampersand, hashmark) strukturális elválasztóként használnak, és ha ezek a karakterek a tartalom részeként jelennének meg kódolás nélkül, az megzavarná az URL értelmezését, és hibás kérésekhez vezetne. Emellett a nem ASCII karakterek, mint az ékezetes betűk, vagy bizonyos speciális szimbólumok, szintén kódolást igényelnek, hogy az URL univerzálisan értelmezhető legyen a különböző rendszerek és platformok között.
Például, ha egy URL tartalmazna egy szóközt, azt %20
-ra kódolnák. Egy &
(ampersand) karakter %26
-ra, egy /
(perjel) pedig %2F
-re. Bár a modern böngészők sok esetben képesek kezelni a nem kódolt karaktereket (különösen a szóközt), a helyes gyakorlat és a maximális kompatibilitás érdekében az URL kódolás elengedhetetlen. A kódolás biztosítja, hogy az URL-ek egyértelműek és értelmezhetők legyenek a különböző rendszerek és platformok számára, elkerülve a félreértelmezéseket vagy a rosszindulatú injektálási kísérleteket.
Példák URL kódolásra gyakori karakterek esetén:
- Szóköz:
%20
(vagy egyes esetekben+
a lekérdezési stringben, de a%20
a szabványosabb és konzisztensebb) - Kérdőjel (?):
%3F
- Ampersand (&):
%26
- Hashmark (#):
%23
- Perjel (/):
%2F
(az útvonalban elválasztóként, de ha az útvonal része, akkor kódolva) - Kettőspont (:):
%3A
- Kötőjel (-): Nem kódolódik, mivel biztonságos karakter, és javasolt a használata a szavak elválasztására.
- Ékezetes karakterek (pl. ő):
%C5%91
(UTF-8 kódolás esetén). Ez a kódolás a karakter UTF-8 bináris értékének hexadecimális reprezentációjából származik.
A kódolás biztosítja, hogy az URL-ek egyértelműek és értelmezhetők legyenek a különböző rendszerek és platformok számára. Ez különösen fontos a dinamikusan generált URL-ek és a felhasználói bevitelből származó adatok URL-be való beépítésekor, ahol a bemeneti adatok tartalmazhatnak speciális vagy nem latin karaktereket. A SEO szempontjából is fontos, hogy az URL-ek tiszták és kódolás nélkül is olvashatóak legyenek a felhasználó számára, amennyire lehetséges. Ezért javasolt a „slugok” (az URL olvasható, kulcsszavakat tartalmazó része) létrehozásakor a speciális karakterek és ékezetek eltávolítása, és helyettük kötőjelek használata, hogy elkerüljük a kódolásból adódó hosszú és nehezen olvasható URL-eket, amelyek rontják a felhasználói élményt és a megoszthatóságot.
Abszolút és relatív URL-ek: mi a különbség és mikor melyiket használjuk?
Az URL-ek két fő kategóriába sorolhatók aszerint, hogy hogyan hivatkoznak egy erőforrásra: abszolút és relatív URL-ek. A különbség megértése alapvető fontosságú a webfejlesztésben és a SEO-ban egyaránt, mivel mindkettőnek megvannak a maga előnyei és hátrányai, és eltérő helyzetekben alkalmazandók.
Abszolút URL-ek
Az abszolút URL az erőforrás teljes, végleges helyét adja meg, beleértve a protokollt, a hosztot és az útvonalat. Mindig egyedileg azonosít egy erőforrást a web globális hálózatán belül, függetlenül attól, hogy honnan hivatkoznak rá. Például: https://www.example.com/termekek/kategoria/termek1.html
. Ez az URL minden szükséges információt tartalmaz a forrás megtalálásához, mintha egy teljes postai címet adnánk meg.
Az abszolút URL-ek előnyei:
- Egyértelműség és megbízhatóság: Pontosan meghatározzák az erőforrás helyét, függetlenül attól, hogy honnan hivatkoznak rá. Nincs kétértelműség, ami csökkenti a hibák kockázatát.
- Hordozhatóság: Ha egy oldalt áthelyeznek vagy más szerveren másolnak, az abszolút linkek továbbra is működni fognak, feltéve, hogy a céloldal elérhető. Ez különösen hasznos, ha a tartalom másolásra vagy külső weboldalakon való hivatkozásra kerül.
- SEO előnyök: A keresőmotorok preferálják az abszolút URL-eket a belső linkek esetében, mivel ez segít elkerülni a félreértelmezéseket és a duplikált tartalom problémáját. Az abszolút URL-ek biztosítják, hogy a linkek következetesen adják át a „link juice”-t (rangsorolási erőt), ami hozzájárul az oldal rangsorolásához. A kanonikus URL-ek és a sitemap-ek kizárólag abszolút URL-eket használnak.
- Tisztább analitika: Az abszolút URL-ek megkönnyítik az analitikai eszközök (pl. Google Analytics) számára a forgalom nyomon követését, mivel minden látogatás egy egyértelmű, teljes URL-hez kapcsolódik.
Hátrányai:
- Hosszabbak: Több karaktert tartalmaznak, ami némileg növelheti a fájlméretet és az adatforgalmat, bár ez modern webes környezetben elhanyagolható.
- Karbantartás: Ha a domain név változik, az összes abszolút linket frissíteni kell, ami nagyméretű weboldalak esetén jelentős feladat lehet.
Az abszolút URL-eket külső linkekhez, kanonikus URL-ekhez, sitemap-ekben és általában a belső linkekhez is ajánlott használni a SEO és a megbízhatóság érdekében. Különösen fontos a weboldal költöztetése vagy domain váltása esetén, hogy az összes abszolút linket frissítsék, és a régi URL-ekről 301-es átirányításokat állítsanak be az újakra.
Relatív URL-ek
A relatív URL egy erőforrás helyét az aktuális dokumentumhoz képest adja meg. Nem tartalmazza a protokollt és a hosztot, hanem csak az útvonal egy részét. Például, ha az aktuális oldal a https://www.example.com/blog/cikk.html
, akkor a ../kep.jpg
relatív URL a https://www.example.com/kep.jpg
-re mutatna (egy szinttel feljebb a könyvtárstruktúrában), míg a ./masik-cikk.html
a https://www.example.com/blog/masik-cikk.html
-re (ugyanabban a könyvtárban). A relatív URL-ek a jelenlegi dokumentum alap URL-jére támaszkodnak a teljes URL felépítéséhez.
A relatív URL-ek előnyei:
- Rövidebbek és tisztábbak: Kevesebb karaktert tartalmaznak, ami könnyebbé teheti a kód olvasását és írását.
- Könnyebb fejlesztés és hordozhatóság helyi környezetben: Fejlesztési környezetben, ahol a domain név változhat (pl. localhostról éles szerverre, vagy különböző tesztelési környezetek között), a relatív linkek rugalmasabbak, mivel nem kell minden környezetben manuálisan módosítani a domain részt.
- Karbantartás (domain váltás esetén): Ha az egész weboldalt áthelyezik egy másik domainre, a relatív linkek automatikusan alkalmazkodnak, mivel nincsenek bekódolva a domain név. Ez egyszerűsíti a migrációs folyamatot, feltéve, hogy a belső struktúra változatlan marad.
Hátrányai:
- Kontextusfüggőség: Jelentésük az aktuális oldal helyétől függ, ami hibákhoz vezethet, ha nem megfelelően használják, vagy ha az oldalt más kontextusba helyezik (pl. RSS feedben vagy e-mailben).
- SEO kockázat: A keresőmotorok nehezebben értelmezhetik őket, és potenciálisan duplikált tartalomhoz vagy hibás indexeléshez vezethetnek, ha a linkek „elveszítik” a kontextusukat (például egy oldal másolásakor vagy hibásan konfigurált szerver esetén). Ha egy relatív URL-t egy másik domainre másolnak, akkor az a másoló domainhez viszonyítva fog feloldódni, ami hibás linket eredményezhet.
- Feltérképezési problémák: Ha a keresőmotorok egy oldalt nem a várt kontextusban találnak meg (pl. egy külső linkről), a relatív URL-ek hibásan oldódhatnak fel, ami feltérképezési hibákhoz vezet.
A relatív URL-eket általában CSS fájlok, JavaScript fájlok és képek hivatkozásaira használják a weboldalon belül, ahol a fejlesztési rugalmasság fontosabb, mint a SEO szempontok. Belső navigációs linkek esetében, különösen nagyobb weboldalakon, az abszolút URL-ek használata ajánlott a SEO stabilitás és a megbízhatóság érdekében. Egy jól átgondolt URL stratégia mindkét típusú URL okos alkalmazását jelenti, figyelembe véve a kontextust és a célokat.
Az URL és a keresőoptimalizálás (SEO) kapcsolata

Az URL nem csupán egy technikai azonosító; a keresőoptimalizálás (SEO) szempontjából is kiemelten fontos szerepet játszik. Egy jól optimalizált URL hozzájárul a jobb rangsoroláshoz, a felhasználói élményhez és a weboldal általános sikeréhez. A Google és más keresőmotorok folyamatosan finomítják algoritmusaikat, de az URL alapvető eleme marad a webes láthatóságnak.
Kulcsszavak az URL-ben
Bár a kulcsszavak szerepe az URL-ben az elmúlt években csökkent a Google algoritmusainak fejlődésével (a Google ma már sokkal inkább a tartalom kontextusára és minőségére fókuszál), még mindig van jelentőségük. Egy releváns kulcsszót tartalmazó URL:
- Segít a felhasználóknak: Az URL-ben lévő kulcsszavak segítenek a felhasználóknak megérteni, miről szól az oldal, még mielőtt rákattintanának a linkre a keresési eredmények között. Ez növelheti az átkattintási arányt (CTR), mivel a felhasználók nagyobb valószínűséggel kattintanak egy olyan linkre, amelynek URL-je is relevánsnak tűnik.
- Segít a keresőmotoroknak: Habár nem domináns rangsorolási faktor, a kulcsszavak az URL-ben még mindig finom jelzést adhatnak a keresőmotoroknak a tartalom relevanciájáról. Ez különösen igaz lehet a niche témákra vagy a kevésbé kompetitív kulcsszavakra.
- Horgonyszövegként funkcionál: Ha valaki egy nyers URL-t másol be egy szövegbe (például egy fórumon vagy egy e-mailben) anélkül, hogy horgonyszöveget adna hozzá, akkor az URL maga lesz a horgonyszöveg. Ha ez az URL releváns kulcsszavakat tartalmaz, az segíthet a rangsorolásban.
Javaslatok a kulcsszavak használatához az URL-ben:
- Használj releváns, fő kulcsszavakat, amelyek pontosan tükrözik az oldal tartalmát.
- Kerüld a kulcsszóhalmozást (keyword stuffing), amely negatívan befolyásolhatja a felhasználói élményt és a Google büntetését vonhatja maga után.
- Használj kötőjeleket (-) a szavak elválasztására, ne aláhúzásjeleket (_) vagy szóközöket. A kötőjeleket a Google szóköznek tekinti, míg az aláhúzásjeleket gyakran egybefüggő szónak. A szóközök kódolást igényelnek (
%20
), ami rontja az olvashatóságot.
URL struktúra és olvashatóság
Az URL struktúrája közvetlenül befolyásolja az olvashatóságot és a felhasználói élményt. Egy tiszta, logikus, könnyen olvasható URL:
- Könnyen megjegyezhető: A felhasználók könnyebben emlékeznek rá, és manuálisan is beírhatják, ami növeli a közvetlen forgalmat.
- Megosztható: Könnyebben megosztható közösségi médiában vagy e-mailben, ami hozzájárul a tartalom vírusmarketingjéhez. A hosszú, kaotikus URL-ek gyakran levágódnak vagy rosszul jelennek meg.
- Bizalmat sugároz: Egy érthető URL professzionálisabbnak tűnik, és növeli a felhasználók bizalmát, ami közvetve befolyásolja az átkattintási arányt.
- Navigációs segítség: Az URL-ben megjelenő hierarchia (pl.
/kategoria/alkategoria/termek
) segíthet a felhasználóknak megérteni, hol vannak a weboldalon belül, és hogyan kapcsolódik az adott oldal a weboldal többi részéhez.
Javaslatok a struktúrához:
- Rövid és tömör: Kerüld a felesleges szavakat és paramétereket. Törekedj arra, hogy az URL a lehető legrövidebb legyen, miközben mégis leíró marad.
- Logikus hierarchia: Tükrözze a weboldal információs architektúráját (pl.
/kategoria/alkategoria/termek
). Ez segít a keresőmotoroknak megérteni a weboldal felépítését és a tartalmak közötti kapcsolatokat. - Kisbetűk: Használj kisbetűket az URL-ben, hogy elkerüld a nagybetű-kisbetű miatti duplikált tartalom problémáját (pl.
/Page/
és/page/
technikai szempontból két különböző URL lehet). - Ékezetek és speciális karakterek kerülése: Bár a modern rendszerek kezelik az ékezeteket (kódolás után), a legjobb gyakorlat a tiszta, ASCII karakterek használata a könnyebb olvashatóság és a szélesebb körű kompatibilitás érdekében.
Kanonikus URL-ek és duplikált tartalom
A duplikált tartalom az egyik legnagyobb SEO probléma, amellyel az URL-ek helytelen kezelése miatt szembesülhetünk. Ugyanaz a tartalom több URL-en is elérhető lehet különböző okokból, például:
- URL paraméterek (pl.
?sessionid=
,?sort=
,?color=
). www
ésnem-www
verziók (www.example.com
vs.example.com
).- HTTP és HTTPS verziók.
- Trailing slash (
/
) a végén (example.com/page/
vs.example.com/page
). - Különböző kis- és nagybetűs változatok.
- Ugyanaz a tartalom több kategóriában is megjelenik (pl.
/kategoria1/termek
és/kategoria2/termek
).
A keresőmotorok számára ez zavaró lehet, mivel nem tudják, melyik verziót kellene indexelniük és rangsorolniuk, ami szétaprózhatja a „link juice”-t és ronthatja az adott oldal rangsorolási potenciálját. Ennek megoldására szolgál a kanonikus URL. A <link rel="canonical" href="teljes_url" />
HTML tag a <head>
szekcióban jelzi a keresőmotoroknak, hogy melyik az adott tartalom preferált vagy „eredeti” URL-je. Ez segít konszolidálni a rangsorolási jeleket és elkerülni a duplikált tartalom büntetését. A kanonikus tag használata különösen fontos az e-kereskedelmi oldalakon, ahol a termékek különböző szűrési és rendezési opciók miatt sokféle URL-en keresztül érhetők el.
Átirányítások (redirects)
Az URL-ek kezelése során gyakran szükség van átirányításokra (redirects), különösen weboldal költöztetés, URL-struktúra változtatás, megszűnt oldalak vagy domain váltás esetén. A helyes átirányítások biztosítják, hogy a felhasználók és a keresőmotorok is a megfelelő helyre kerüljenek, és a régi URL-ekhez kapcsolódó SEO érték is átadódjon az új URL-nek, minimalizálva a forgalom és a rangsorolás elvesztését.
- 301-es átirányítás (Moved Permanently): Ez a legfontosabb SEO szempontjából, mivel azt jelzi, hogy az oldal véglegesen áthelyezésre került, és a „link juice” nagy része (a Google szerint körülbelül 90-99%) átadódik az új URL-nek. Weboldal átalakítás, domain váltás, vagy HTTP-ről HTTPS-re való migráció esetén elengedhetetlen. Ennek hiányában a régi URL-ekhez mutató linkek értéke elveszne, és a keresőmotorok 404-es hibákat találnának.
- 302-es átirányítás (Found / Moved Temporarily): Ideiglenes átirányításra szolgál, és elméletileg nem adja át a SEO értéket. Ritkán használatos SEO kontextusban, legfeljebb rövid távú kampányok vagy A/B tesztelés esetén, ahol a tartalom várhatóan visszatér az eredeti URL-re. Hosszú távú használata SEO szempontból káros lehet.
- Meta Refresh: Kliens oldali átirányítás, amelyet HTML kóddal vagy JavaScripttel valósítanak meg. Nagyon lassú, felhasználóbarátlan, és a keresőmotorok sem szeretik. SEO szempontból kerülendő.
A rosszul kezelt átirányítások 404-es hibákhoz (oldal nem található) vagy láncolt átirányításokhoz (redirect chains) vezethetnek, ami negatívan befolyásolja a felhasználói élményt és a SEO-t, mivel a keresőmotoroknak több erőforrást kell felhasználniuk a helyes oldal megtalálásához, vagy akár fel is adhatják a feltérképezést.
HTTPS és a biztonságos URL-ek
Ahogy korábban említettük, a HTTPS protokoll ma már alapvető elvárás. A Google nyíltan kijelentette, hogy a HTTPS egy rangsorolási faktor, és a böngészők egyre inkább figyelmeztetik a felhasználókat a nem biztonságos HTTP oldalak látogatásakor, ami a felhasználói bizalom elvesztéséhez vezethet. A HTTPS használata nem csupán a SEO-t javítja, hanem növeli a felhasználók bizalmát és védi az adataikat. Az átállás során minden belső és külső linket frissíteni kell HTTPS-re, és a régi HTTP URL-eket 301-es átirányítással kell az új HTTPS verziókra irányítani. A HTTPS a modern web alapja, és elengedhetetlen a biztonságos és megbízható online jelenléthez.
URL paraméterek kezelése a Google Search Console-ban
A Google Search Console (GSC) egy értékes eszköz a webmesterek számára az URL paraméterek kezelésére. A GSC-ben beállítható, hogy a Googlebot hogyan kezelje a különböző URL paramétereket (pl. sessionid
, sort
, filter
). Ez segít megelőzni a duplikált tartalom problémáját és optimalizálni a feltérképezési költségvetést (crawl budget) azáltal, hogy a Googlebot nem pazarolja idejét ugyanazon tartalom több változatának feltérképezésére. A paraméterkezelés funkcióval jelezhetjük a Google-nek, hogy mely paraméterek nem változtatják meg az oldal tartalmát jelentősen, vagy melyeket kell figyelmen kívül hagyni az indexelés során. Ezáltal a Googlebot hatékonyabban tudja feltérképezni a weboldalt, és az oldalak relevánsabbá válnak a keresési eredményekben.
A helyes URL-struktúra kialakítása és az URL-ek folyamatos karbantartása alapvető fontosságú a hosszú távú SEO sikerhez. Egy átgondolt URL-stratégia nemcsak a keresőmotoroknak kedvez, hanem a felhasználók számára is egyértelműbbé és megbízhatóbbá teszi a weboldalt, hozzájárulva a jobb felhasználói élményhez és a magasabb konverziós arányokhoz.
Az URL és a felhasználói élmény (UX)
Az URL-ek szerepe nem merül ki a technikai működésben és a SEO-ban; jelentős hatással vannak a felhasználói élményre (UX) is. Egy jól megtervezett URL hozzájárul a weboldal átláthatóságához, megbízhatóságához és használhatóságához, ami közvetlenül befolyásolja a látogatók elégedettségét és a visszatérő forgalmat.
Olvashatóság és érthetőség
Amikor egy felhasználó meglát egy URL-t, legyen az egy keresési eredményben, egy megosztott linken vagy a böngésző címsorában, azonnal felméri annak tartalmát és relevanciáját. Egy olvasható és érthető URL, amely emberi nyelven íródott, és tükrözi az oldal tartalmát, sokkal vonzóbb és informatívabb, mint egy véletlenszerű karakterekből álló sorozat. Az ilyen URL-ek egyfajta „preview”-t nyújtanak az oldal tartalmáról, még mielőtt a felhasználó rákattintana.
Például, a https://www.example.com/blog/2023/legjobb-seo-tippek-url-hez
sokkal informatívabb és megbízhatóbbnak tűnik, mint a https://www.example.com/post.php?id=12345&cat=blog&date=2023
. Az előbbi azonnal elárulja, hogy egy blogbejegyzésről van szó, amely 2023-ban készült, és SEO tippekről szól az URL-ekkel kapcsolatban. Ez növeli a felhasználói bizalmat és az átkattintási hajlandóságot, mivel a felhasználó pontosan tudja, mire számíthat a linkre kattintva.
Az érthető URL-ek emellett segítik a felhasználókat abban is, hogy tudják, hol vannak a weboldalon belül (ezt gyakran „breadcrumbs in URL”-nek nevezik). Ha az URL tükrözi a weboldal hierarchiáját, a felhasználók könnyebben navigálnak, és megértik a tartalom helyét a teljes struktúrában. Ez a vizuális tájékozódás különösen hasznos nagyméretű weboldalakon, ahol a felhasználók könnyen elveszhetnek a sok aloldal között.
Megoszthatóság és memorizálhatóság
Egy rövid, tiszta és releváns URL könnyebben megosztható a közösségi médiában, e-mailben vagy azonnali üzenetküldő alkalmazásokban. A felhasználók szívesebben másolnak és illesztenek be egy értelmes URL-t, mint egy hosszú, kaotikus karakterláncot. Ezáltal az URL maga is marketing eszközzé válik, növelve a tartalom terjedését és a „word-of-mouth” marketing hatékonyságát. A közösségi média platformok gyakran levágják a hosszú URL-eket, ami rontja az olvashatóságot és az információátadást, ezért a tömör URL-ek előnyben részesülnek.
Hasonlóképpen, egy egyszerű, releváns URL könnyebben megjegyezhető. Ha a felhasználók emlékeznek egy URL-re, vagy annak egy részére, nagyobb eséllyel térnek vissza az oldalra közvetlenül, vagy hivatkoznak rá másoknak. Ez különösen fontos a branding szempontjából, és hozzájárul a közvetlen forgalom növeléséhez. Egy könnyen megjegyezhető domain és URL segíti a márkafelismerést és a felhasználói lojalitást.
Bizalmi tényező
Az URL-ek vizuális megjelenése is befolyásolja a felhasználók bizalmát. Egy HTTPS protokollal kezdődő URL, különösen ha zöld lakat ikon kíséri a böngésző címsorában, azonnal biztonságérzetet ad. Ez azt jelzi, hogy az oldal hitelesített, és az adatátvitel titkosított, ami elengedhetetlen a személyes adatok védelmében és az online tranzakciók során. Ezzel szemben egy HTTP URL, vagy egy gyanúsan hosszú, sok paramétert és ismeretlen karaktert tartalmazó URL riasztó lehet, és a felhasználók hajlamosabbak elkerülni az ilyen oldalakat, attól tartva, hogy adathalászat vagy rosszindulatú szoftverek áldozatai lesznek. A böngészők figyelmeztetései a nem biztonságos oldalakról tovább erősítik ezt a bizalmatlanságot.
A tiszta, jól strukturált és biztonságos URL-ek tehát nem csupán technikai optimalizálást jelentenek, hanem a weboldal hitelességét és megbízhatóságát is erősítik a felhasználók szemében. Ez közvetlenül befolyásolja a weboldal látogatottságát, az átkattintási arányt és a konverziókat, hiszen a felhasználók sokkal szívesebben lépnek interakcióba egy megbízható és átlátható weboldallal.
Gyakori URL-lel kapcsolatos problémák és megoldásuk
Bár az URL-ek alapvetőek a web működéséhez, számos probléma adódhat a kezelésük során, amelyek negatívan befolyásolhatják a weboldal teljesítményét, a felhasználói élményt és a SEO-t. Ezen problémák felismerése és proaktív kezelése elengedhetetlen a weboldal hosszú távú sikeréhez. Íme néhány a leggyakoribbak közül, és javaslatok a megoldásukra.
404-es hibák (nem található oldal)
A 404-es hiba akkor jelentkezik, amikor egy felhasználó vagy egy keresőmotor egy olyan URL-t próbál elérni, amely nem létezik a szerveren. Ez az egyik leggyakoribb és legfrusztrálóbb hibaüzenet a felhasználók számára, és negatívan befolyásolja a SEO-t is, mivel a keresőmotorok nem tudják indexelni az oldalt, és a linkek értéke is elveszhet.
Ennek okai lehetnek:
- Elírt URL a felhasználó vagy egy külső link által.
- Megszűnt oldal, amelyre még mutatnak belső vagy külső linkek.
- Megváltozott URL-struktúra megfelelő átirányítás nélkül.
- Törölt tartalom, amit nem irányítottak át egy releváns, élő oldalra.
- Hibás hivatkozás a weboldal belső linkjei között.
Megoldás:
- 301-es átirányítások: Ha egy oldal URL-je megváltozott vagy a tartalom átkerült egy másik helyre, állítsunk be