Laravel webshop SEO: hogyan építs keresőbarát rendszert?

Az egyedi Laravel webshop nem attól lesz keresőbarát, hogy Laravel. A keretrendszer annyit ad, hogy minden URL, minden kiszolgált HTML sor és a sitemap is a te körödben marad. Ezért a hibák is a tiéid lesznek, és egyedi webshopnál pont ugyanazt a négy-öt hibát látjuk vissza, amikor átvilágítunk egy oldalt.

Ez a cikk azokról szól. Nem a SEO alapjairól, hanem arról, amit Laravel alapon konkrétan el kell dönteni, lehetőleg még az indulás előtt.

1. Az URL-szerkezet, amit indítás után már fájdalmas javítani

A beszédes útvonal (/ferfi-sportcipo/nike-air-max-90-fekete) helyett az azonosítós (/products?id=12345) ma már ritka, ezt a legtöbb fejlesztő megoldja. Amit viszont sokan kihagynak: mi történik, amikor az ügyfél átírja a termék nevét.

Ha a slug a névből képződik, és nincs mögötte átirányítás-tábla, akkor minden terméknév-javítás egy 404-es oldalt hagy maga után, ráadásul pont azon az URL-en, ami eddig hozta a forgalmat. A megoldás egy egyszerű redirects tábla az adatbázisban: slug-váltáskor a régi érték bekerül, és egy middleware 301-gyel küldi tovább. Ez fél nap munka a fejlesztés elején, és évekig nem kell hozzányúlni.

Ugyanide tartozik a két unalmas döntés, amit érdemes előre elintézni: legyen-e záró perjel az URL végén, és mi történik a nagybetűs változattal. Mindkettőre legyen egy kanonikus alak, a többi 301-gyel arra mutasson.

2. A szűrők, ahol a legtöbb egyedi webshop elvérzik

Ez a leggyakoribb komoly hiba, amit egyedi webshopoknál látunk. A kategóriaoldali szűrők (szín, méret, márka, ársáv, rendezés) query stringet generálnak, és ha ezek mind bejárhatók, egy 300 termékes webshopból tízezres nagyságrendű URL lesz. A Google ezt végigjárja, elkölti rá a crawl budgetét, és közben a valódi termékoldalak érkezése lelassul.

Amit ilyenkor javasolni szoktunk:

• Minden szűrt nézet kanonikus URL-je a tiszta kategóriaoldal legyen.
• A többparaméteres kombinációk kapjanak noindex, follow jelölést, a rendezés és a nézetváltó paraméterek pedig nofollow linket.
• Ami tényleg keresett kombináció („fekete férfi sportcipő”), az ne szűrő legyen, hanem saját, indexelhető aloldal saját szöveggel és címmel.

Az utolsó pont a lényeg. Nem az a cél, hogy minden szűrő bekerüljön a Google-be, hanem hogy az a húsz-harminc kombináció, amire tényleg keresnek, kapjon rendes oldalt.

3. Lapozás

Az ?page=2 ne a kategória első oldalára kanonizáljon. Ez régi, makacs tanács, és azzal jár, hogy a második oldaltól kezdve a termékekre mutató belső linkek eltűnnek a Google szeme elől. A lapozott oldal önmagára kanonizáljon, és maradjon indexelhető, vagy ha nem akarod indexben látni, akkor noindex, follow, de a linkek maradjanak bejárhatók.

4. Mi legyen a kifutó termékkel?

Erre minden webshopnál szükség van egy szabályra, különben a fejlesztő és az ügyfél mást csinál. Amit használni szoktunk:

• Ideiglenesen elfogyott: az oldal marad, a JSON-LD-ben OutOfStock, és látszódjon hasonló termék.
• Végleg kifutott, de van utódja: 301 az utódra.
• Végleg kifutott, nincs utódja és nincs forgalma: 410, nem 404. A Google a 410-et gyorsabban veszi tudomásul.

Amit ne csinálj: minden kifutott terméket a főoldalra irányítani. Azt a Google lágy 404-nek kezeli, tehát ugyanott vagy, csak körbe.

5. Amit a Google tényleg lát a te frontendedből

Laravel alatt ma három irány él egymás mellett: klasszikus Blade, Livewire, vagy Inertia és Vue. Mindhárommal lehet keresőbarát webshopot építeni, de egy dolgot ellenőrizni kell: a kategórialista és a termékleírás benne van-e a szerver által kiküldött HTML-ben.

Ha a termékek csak egy API-hívás után jelennek meg a böngészőben, vagy a leírás egy „Tovább” gomb mögött töltődik be, akkor a Google láthatja később, de nem garantáltan. Egyszerű teszt: nézd meg a nyers forrást (JavaScript nélkül), és keress rá egy terméknévre. Ha nincs benne, ott van dolgod.

6. Sebesség Laravel oldalon

A Google három értéket néz valós látogatói adatból, a 75. percentilisen: LCP 2,5 másodperc alatt, INP 200 ezredmásodperc alatt, CLS 0,1 alatt. Az adat 28 napos gördülő ablakból jön, tehát egy javítás hatása csak három-négy hét múlva látszik a Search Console-ban. Ezt érdemes előre tisztázni, különben másnap keresi mindenki a változást.

Ami Laravelen a leggyakrabban hoz érezhető javítást, nagyjából ebben a sorrendben:

• Az N+1 lekérdezések kiirtása a kategórialistán. Egy 48 termékes lista könnyen kerül 200 lekérdezésbe, ha a képek és a változatok nincsenek eager loadolva.
• Deploy után config:cache, route:cache, view:cache, és ahol elbírja a tartalom, ott teljes válasz-cache a kategóriaoldalakra.
• Képek WebP formátumban, több méretben, fix szélesség és magasság attribútummal. Ez utóbbi a CLS-t javítja, és szinte ingyen van.
• A lista első sorának képei ne legyenek lazy loadoltak, a többi igen.

7. Strukturált adat, ami nem hazudik

A termékoldalra Product JSON-LD való, névvel, képpel, árral, pénznemmel és készletinformációval, plusz BreadcrumbList a navigációhoz. Laravelben ezt egy Blade komponensből érdemes generálni, közvetlenül a modellből.

Egy szabály van, amit nem lehet megkerülni: a strukturált adatban szereplő ár és készlet egyezzen azzal, ami az oldalon látszik. Ha a JSON-LD-ben még a régi akciós ár van, mert a cache nem ürült, az a Merchant Center oldalán is probléma lesz, nem csak SEO-ban.

8. Sitemap adatbázisból

A dinamikus sitemap generálás Laravelben néhány órás feladat, de két dolgot könnyű elrontani. Az egyik, hogy csak indexelhető, kanonikus és 200-as választ adó URL kerüljön bele, tehát ne legyen benne a szűrt nézet, a kosár, a be nem kapcsolt termék és a 301-es régi slug. A másik a méret: egy sitemap fájl legfeljebb 50 000 URL-t és 50 MB-ot tartalmazhat tömörítés nélkül, felette index fájlra kell bontani.

9. A CMS, amit az ügyfél is használ

Ez az a pont, amit fejlesztőként a legkönnyebb elfelejteni. Ha a title és a meta description mező nincs ott a termék szerkesztő felületén, akkor soha nem lesz kitöltve, mert senki nem fog adatbázist írni miatta.

A latogataskonyvek.hu webshopnál, amit mi fejlesztettünk, pont ez volt az egyik kimondott cél: saját CMS, amit a megrendelő tényleg kezelni tud. Ehhez jó alapértelmezett értékek kellenek (a terméknévből képzett title, a leírás első mondatából képzett description), és mellette a lehetőség, hogy felülírja, ahol számít.

Mikor ne egyedi Laravel webshop legyen?

Őszintén: a felsoroltak nagy részét egy Shoprenter vagy UNAS bérelt webáruház is tudja, részben már a dobozból. Ha a webshopod nagyjából szokásos módon működik, nincs különleges árazás, konfigurátor vagy rendszerkapcsolat, akkor az egyedi fejlesztés SEO-ból önmagában nem fogja megérni.

Az egyedi Laravel akkor jön jól, ha van olyan üzleti logika, amit a bérelt platform nem enged, vagy ha annyi terméked és kategóriád van, hogy a fenti döntéseket (szűrők, kifutó termékek, sitemap-logika) tényleg testre kell szabni. Erről többet a webáruház készítés oldalon írunk.

Mivel kezdd, ha már él a webshop?

Nézd meg a Search Console Oldalak riportját, és hasonlítsd össze a felfedezett és az indexelt URL-ek számát a termékek számával. Ha a felfedezett URL-ek száma többszöröse a termékekének, akkor szinte biztosan a szűrők generálják a különbséget, és ott érdemes kezdeni. Ez általában egy-két napos fejlesztés, és többet hoz, mint bármilyen szövegcsiszolás.

Ha inkább ránézne valaki, a keresőoptimalizálás oldalunkon látod, hogyan szoktuk átvilágítani egy webshop technikai állapotát.

Utoljára ellenőrizve: 2026. szeptember.