A Drupal SEO hírneve megalapozatlan. Kérdezzen körbe, és valaki azt mondja majd, hogy a Drupal alapból jó a keresőknek, rendszerint egy másik platformról őrzött, tizenöt éves emlék alapján. Egy gyári Drupal 11 telepítés nem hoz magával meta description mezőt, XML sitemapet, automatikus átirányítást URL-változáskor, és a tartalom a /node/123 címen válaszol addig, amíg valaki kézzel be nem gépel egy álnevet.

Ez nem a projekt kritikája. A mag szándékosan kicsi felületet tart, és minden állásfoglalást igénylő döntést a közösségi modulokba tol ki, éppen ezért hangolható egy nagy Drupal oldal pontosabban, mint amit a legtöbb platform megenged. Azt viszont jelenti, hogy az “alapból működik” fordulat rengeteg terhet visz, és hogy egy Drupal oldal keresőteljesítménye szinte teljesen azon múlik, mely modulok kerültek fel az első napon, és hogyan állította be őket valaki.

Az alábbi leírás ezt a modulkészletet mutatja be 2026 szeptemberi állapotában: mit tud a mag, mely közösségi modulok pótolják azt, amit más rendszerek ingyen adnak, milyen hibák léteznek csak Drupalon, és mennyibe kerül rendbe hozni egy oldalt, ahol ebből semmi sem történt meg az elején.

Jó a Drupal SEO szempontjából alapból? Nem. A mag ad útvonal-álneveket, canonical címkéket és erős többnyelvű útválasztást, de nem ad meta descriptiont, XML sitemapet, átirányításkezelést és strukturált adatot. Ezek négy közösségi modulból jönnek: Pathauto, Metatag, Simple XML Sitemap és Redirect. Egy Drupal oldal ezek nélkül nem rosszul optimalizált, hanem optimalizálatlan.

Mit tud valójában a Drupal magja

A mag három dolgot ad, ami számít, és mindhárom tényleg jó.

A mag Path modulja lehetővé teszi, hogy bármely útvonalhoz olvasható álnevet rendeljen, így egy node a /services/tax-advice címen válaszol a belső útvonala helyett. A mag eltárolja az álnevet, és azon keresztül oldja fel a kérést. Amit a mag nem tesz meg, az az álnév kitalálása, vagyis egy kétezer nodeot tartalmazó oldalon valakinek kétezer álnevet kellene begépelnie, és ezt a gyakorlatban soha senki nem teszi meg.

A mag link-relációkat is kiír az entitásoldalakon. Egy node megtekintése rel="canonical" értéket ad az álnévvel ellátott URL-re és rel="shortlink" értéket az álnév nélkülire, ami több annál, mint amit több kereskedelmi platform bővítmény nélkül elér. Éppen ez a viselkedés teszi az alább leírt duplikált útvonalak problémáját általában elviselhetővé és nem végzetessé.

A harmadik a nyelv. A mag többnyelvű rétege kezeli az útvonalelőtagokat, a nyelvenkénti álneveket és a lefordított entitásokon megjelenő alternatív nyelvi hivatkozásokat, és ez a Drupal keresős történetének legerősebb része.

Minden más közösségi. Nincs meta description mező egy tartalomtípuson, amíg fel nem vesz egyet, nincs sitemap, nincs átirányítási tábla, egy node törlése pedig egy 404-et hagy maga után, és semmi mást.

A négy modul, ami gyakorlatilag kötelező

Több tucat modul visel SEO címkét a drupal.org oldalon. Négy közülük nem opcionális, és az a Drupal fejlesztés, amelyik bármelyiket kihagyja, olyan lyukkal indul, ami a versenytársainál nincs meg.

Pathauto

A Pathauto tokenmintákból állítja elő az álneveket, így egy blog/[node:title] alakú minta a node mentésekor automatikusan létrehozza az álnevet. Ez áll a legközelebb ahhoz, hogy a Drupalban mindenhol telepített modul legyen: 464 471 oldal jelenti a használatát, a jelenlegi stabil kiadás pedig, a 2026. május 4-i 8.x-1.15, támogatja a Drupal 10.2 és 11 verziót. Függ a Token modultól.

Az a beállítás dönti el, hogy a Pathauto segít vagy árt, amelyik a frissítési műveletet szabályozza, vagyis azt, mi történik, ha egy cím megváltozik, és a minta más álnevet ad. A Pathauto nem csinálhat semmit, lecserélheti az álnevet, vagy létrehozhatja az újat és mellé egy átirányítást a régiről. A harmadik lehetőség a helyes, és csak akkor létezik, ha a Redirect modul telepítve van. A gyengébb alapértéken hagyott oldalak csendben több élő álnevet gyűjtenek nodeonként.

Metatag

A Metatag az a mód, ahogyan egy Drupal oldal egyáltalán meta descriptionhöz jut, az Open Graph és Twitter Card kimenettel együtt. Damien McKenna 2012 óta karbantartja, 332 868 oldal jelenti a használatát, a 2025 szeptemberi 2.2.0 kiadás pedig Drupal 10.3 vagy 11 verziót igényel.

Entitástípusonként és bundle-önként megadott alapértékekkel dolgozik, amelyeket tokenmintaként ír le, és amelyekre nodeonkénti felülírások rétegződnek. A szokásos hiba az a minta, amelyik egy egész tartalomtípuson azonos eredményt ad, több száz olyan oldalt gyártva, amelyek egyetlen descriptiont osztanak meg. Ez rosszabb, mint ha nem lenne description, mert azt üzeni a robotnak, hogy az oldalak felcserélhetők.

Simple XML Sitemap

A mag semmilyen sitemapet nem szállít. A Simple XML Sitemap a szokásos válasz, 137 418 oldal használja, a 2025. november 26-i 4.2.3 kiadás pedig Drupal 10.3 vagy 11 verziót igényel. Entitásokat, nézeteket és egyedi hivatkozásokat indexel, és hreflang- meg képbejegyzéseket ad ki, ami többnyelvű oldalaknál rendkívül sokat számít.

Bundle-önként állítsa be, ne globálisan. Az alapértelmezett kísértés az, hogy mindent felvesz, ami a taxonómiakifejezések oldalait, a felhasználói profilokat és a szűretlen nézetlistákat is betolja a sitemapbe, és azt közli a keresőkkel, hogy a leggyengébb oldalai élveznek elsőbbséget.

Redirect

A Redirect kézi átirányításokat ad, és ami fontosabb, a kanonikus URL kikényszerítését: minden nem kanonikus kérést a tartalom kanonikus útvonalára tud irányítani. 265 749 oldal használja, a 2026. április 24-i 8.x-1.13 pedig támogatja a Drupal 10 és 11 verziót.

Egy fenntartást érdemes kimondani. A projektoldal jelenleg “seeking co-maintainers” jelzést visel, ami egy ennyire teherhordó modulnál figyelendő karbantartási kockázat, nem pedig ok a kerülésére. Továbbra is a Drupal biztonsági közlemények szabályzata alá tartozik.

Drupal SEO csapdák, amik más platformokon nincsenek

Minden node-nak legalább két élő URL-je van

Ez lepi meg leginkább a más rendszerekből érkezőket. Az álnév felvétele Drupalban nem vonja ki a forgalomból a belső útvonalat. A /node/123 továbbra is 200-zal és a teljes oldallal válaszol, és így tesz minden álnév, amit az a node valaha kapott, ha a frissítési művelet hagyta őket fennmaradni.

A mag canonical címkéje mérsékli a kárt, és a Google erős jelzésként kezeli a canonical megjelölést, nem utasításként, az átirányításokkal egy szinten és a sitemapbe kerülés felett. Az erős jelzés azonban nem garancia. A megbízható megoldás a Redirect modul kanonikus kikényszerítése, amely a duplikátumokat állandó átirányításokká alakítja, így nem marad összevonnivaló.

A taxonómiakifejezések oldalai elszaporodnak

A mag minden taxonómiakifejezéshez listaoldalt generál. Egy szabad címkézésű szótárral rendelkező oldalon ez címkénként egy oldalt jelent, amelyek többsége egy vagy két nodeot tartalmaz, mindegyik sablonos címmel és description nélkül. Több százuk olyan tartalomhígulási gond, amit senki nem hozott létre szándékosan.

Szótáranként döntsön, ne az egész oldalra egyszerre. A valódi szerkesztői értékkel bíró kategóriák indexelhetők, és kézzel írt descriptiont kapnak. A szabad címkézésű szótárak kimaradnak a sitemapből, és a legtöbb esetben noindexet kapnak.

A nézetek lapozása és a ?page= nyomvonal

A mag minden nézetlistája ?page= paraméterrel lapoz, és mindegyik ilyen cím külön URL. A Google iránymutatása szerint egy sorozat minden lapjának saját URL-je és saját canonicalja legyen, ahelyett hogy az első lapra kanonizálnák, és a rel next meg prev már nincs használatban.

A Drupalra jellemző rész az, hogy ugyanannak a nézetnek a kitett szűrői és rendezései összeszorzódnak a lapozóval. Egy három kitett szűrővel és negyven eredményoldallal működő lista sokkal több megcímezhető URL-t hoz létre, mint amennyi tartalma van, és mindegyik lerenderelődik.

A facettek és a paraméterrobbanás

A facettás keresés, jellemzően a Search API fölé tett Facets modul az a pont, ahol ez már nem rendetlenség, hanem bejárási keret gondja. A 2026. szeptember 1-én kiadott Facets 3.0.6 támogatja a Drupal 10.1 és 11 verziót, és 56 746 oldal használja. Szintén “seeking co-maintainers” jelzést visel.

A Google figyelmeztet, hogy a robotok hatalmas mennyiségű facettás navigációs URL-t járnak be, mielőtt megállapíthatnák, hogy ezek sehová hasznos helyre nem vezetnek, és hogy ez felemészti mind az Ön bejárási keretét, mind az ő számítási kapacitásukat. Döntse el korán, mely facettkombinációk indexelhetők, zárja ki a többit, és tartsa stabilan a paraméterek sorrendjét, hogy azonos szűrőkészlet mindig azonos URL-t adjon.

A közzétételi állapotok ingadozása

Egy nem közzétettként létrehozott node, amely munkacímet kap, majd egy héttel később más címmel jelenik meg, egy álnevet hoz létre a létrehozáskor és egy másikat a közzétételkor. Rossz frissítési művelet mellett mindkettő élő és bejárható marad. Szorozza ezt egy szerkesztőségi csapattal és egy évnyi termeléssel, és az álnévtábla nagyobb lesz a node-táblánál, ami pontosan az a minta, amit egy SEO audit keres, amikor az élő URL-eket a közzétett nodeokhoz méri.

Strukturált adat Drupalban

Két út van, és a választás többet nyom a latban, mint amennyinek látszik.

A Schema.org Metatag a Metatagot bővíti ki úgy, hogy JSON-LD-t adjon ki az oldal fejlécében, több mint huszonöt sématípust lefedve. A 2026. február 19-i 3.0.4 verzió támogatja a Drupal 9, 10 és 11 kiadást, és 66 363 oldal használja. A Redirecthez és a Facetshez hasonlóan ez is társkarbantartókat keres.

Előnye, hogy örökli a Metatag teljes öröklődési modelljét: bundle-önkénti alapértékek, mezőértékeket húzó tokenek, nodeonkénti felülírások, és szerkesztők, akik soha nem látnak nyers JSON-t. Korlátja, hogy csak azt tudja kifejezni, amit a modul modellez, a mélyen egymásba ágyazott séma pedig, amire egy terméknek szüksége van, amint ajánlatok, vélemények és visszaküldési szabályzat is szóba kerül, nehézkesen épül fel tokenmezőkből.

A Twig sablonban kézzel írt JSON-LD teljes irányítást ad, és a szerkesztői felületet veszi el cserébe. Egy maroknyi sablonnal és kéznél lévő fejlesztővel működő oldalon ez gyakran a jobb csere. Hatvan tartalomtípussal és egy tartalomcsapattal működő oldalon nem az, mert minden sémamódosítás élesítéssé válik.

Válasszon egy utat. A leggyakrabban látott hiba az, hogy mindkettő fut párhuzamosan, és két olyan Article blokkot ad ki, amelyek ellentmondanak egymásnak a közzététel dátumában.

Többnyelvű Drupal és a hreflang

Itt érdemli ki a Drupal valóban a hírnevét, és ezt ki kell mondani, mert a cikk többi része hiányosságokról szól.

A mag hozza a nyelvi modulokat, és ha a tartalomfordítás be van kapcsolva, a Drupal minden közösségi segítség nélkül kiírja az alternatív nyelvi hivatkozásokat a lefordított entitásokon. Az útvonalelőtagok, a nyelvenkénti álnevek és a nyelvenkénti menük úgy működnek, ahogy érkeznek.

A Google elvárásai a lokalizált változatokkal szemben az, hogy minden változat felsorolja önmagát és az összes többit is, hogy a megjelölések kétirányúak legyenek, és hogy legyen x-default tartalékként. A Drupal fordítási modellje az első kettőt automatikusan teljesíti, mert az alternatívák a fordítási készletből állnak elő, nem szerkesztői gépelésből. Ez valódi előny azokkal a platformokkal szemben, ahol a hreflang egy bővítménymező, amit el lehet felejteni.

Két dolog azért mégis elromlik. Az x-default értéket nem állítja be senki Ön helyett, azt a Metatagon vagy egy sablonon keresztül kell pótolni. A részleges fordítási készletek pedig olyan alternatívákat gyártanak, amelyek a forrásnyelvre visszaeső oldalakra mutatnak, ami rosszabb jelzés, mint a megjelölés teljes elhagyása.

Teljesítmény és Core Web Vitals

A Drupal gyorsítótár-rétegei a magban vannak, jók, és gyakran kikapcsolva maradnak egy hibakeresési munkamenet után, amelynek lezárására senki nem emlékezett.

A renderelési gyorsítótár a részleteket cache-elhetőségi metaadatokkal tárolja: cache-címkékkel, amelyek leírják, mely adatoktól függ egy részlet, cache-kontextusokkal, amelyek leírják, mi szerint változik, és egy maximális élettartammal. A címkék automatikusan érvénytelenednek, amikor a mögöttes entitás megváltozik. Ha a metaadat rossz, vagy elavult oldalakat szolgál ki, vagy egyáltalán nem gyorsítótáraz.

Az Internal Page Cache teljes oldalakat szolgál ki a névtelen látogatóknak. A Dynamic Page Cache bármely felhasználónak kiszolgál oldalakat úgy, hogy a személyre szabott részek kivételével mindent gyorsítótáraz. A BigPipe, amely a Drupal 8.1 óta a magban van és a 8.5 óta a szabványos telepítési profil része, ezután folyamként küldi utána a személyre szabott helyőrzőket, miután az első válasz már kiment.

A Core Web Vitals szempontjából kevés dolog számít. A BigPipe javítja az érzékelt betöltést, és ronthatja a Cumulative Layout Shift értékét, ha az általa kitöltött helyőrzőknek nincs lefoglalt helyük. A Largest Contentful Paint egy Drupal oldalon rendszerint a fejlécképeken és az összevont CSS-csomagon múlik, nem a renderelési gyorsítótáron. A Drupal 11.4 hozzáadta a Brotlival tömörített CSS- és JavaScript-fájlok előállítását, ha a PHP-bővítmény elérhető, ami egyértelmű nyereség minden olyan oldalon, amely maga szolgálja ki a fájljait.

Mit tör el egy főverziós frissítés

Egy Drupal főverziós frissítés nem platformváltás, de a keresési láthatóságot meghatározott és ismétlődő módokon rontja el.

A közösségi modulok a szokásos ok. Ha a Metatag nem áll készen a célverzióra, és az oldal nélküle megy élesbe, az összes meta description egyszerre eltűnik, és senki nem veszi észre addig, amíg két héttel később le nem esnek a megjelenések. Ugyanez igaz a sitemap modulra, és ami rosszabb, a Redirectre, mert annak elvesztése leállítja a kanonikus kikényszerítést, és minden régi álnevet visszahoz az életbe.

A második ok a konfiguráció, amely nem éli túl a költözést. A Metatag alapértékek, a Pathauto minták és a sitemap bundle-beállításai mind a konfigurációban élnek, és az az újraépített oldal, amely a tartalmat importálja, a konfigurációt viszont nem, alapértelmezett mintákkal és azonos tartalomhoz tartozó eltérő URL-ekkel jön vissza.

Készítsen teljes bejárást, mielőtt belekezd, rögzítve minden oldal URL-jét, státuszkódját, címét, descriptionjét és canonicalját, majd vesse össze ugyanazzal a bejárással utólag. A Drupal migrációs útmutatónk végigveszi a verzióutakat és a hozzájuk tartozó határidőket.

Hol tartanak most a Drupal verziók

Az időzítés megváltoztatja, mit érdemes először elvégezni. A Drupal 11.4.0 2026. július 1-én érkezett, a 11.4.x ág pedig 2027 júniusáig kap biztonsági támogatást. A 2022. december 15-én kiadott Drupal 10 2026. december 9-én éri el az életciklusa végét, a Drupal 12 pedig 2026. december 7-ének hetére van ütemezve, 2026 szeptemberének közepén várható bétával.

Ebből az következik, hogy egy Drupal 10 oldalnak e sorok írásakor nagyjából három hónap biztonsági lefedettsége maradt. Minden Drupal 10 oldalra megrendelt SEO munkát a frissítés utánra érdemes ütemezni, nem elé, mert fordítva kétszer fizet: egyszer a metaadatok javításáért, majd újra, amikor egy modul verzióugrása megváltoztatja a kimenetet.

A Drupal 11.1-től 11.4-ig PHP 8.3 és 8.4 alatt fut, míg a Drupal 10 legalább PHP 8.1 verziót kér. Osztott tárhelyen nagyon gyakran a PHP alsó határa az igazi akadály, nem maga a Drupal munka.

Mennyibe kerül egy Drupal SEO munka

Először határolja be rendesen. Egy Drupal SEO munka nem jelentés, hanem konfigurációs és sablonmunka egy adott kódbázison belül, és amit átad, az egy megváltozott oldal, nem egy dokumentum.

Az alapaudit lefedi a négy modulból álló készletet és annak beállításait, az álnév- és átirányítási táblákat, a taxonómia és a nézetek kitettségét, a sitemap tartalmát, a strukturált adat kimenetét és a gyorsítótár-rétegeket. Néhány száz nodeot tartalmazó oldalon ez három-öt munkanap. A brit technikai SEO napidíjak jellemzően £600 és £1,200 között mozognak, így egy ilyen alakú technikai SEO audit £2,000 és £5,000 közé esik, a tapasztalati szinttől és az oldal méretétől függően.

A megvalósítás külön tétel, és rendszerint nagyobb. A Pathauto, a Metatag, a Simple XML Sitemap és a Redirect telepítése és beállítása egy meglévő tartalmat hordozó élő oldalon azt jelenti, hogy tömegesen kell álneveket generálni, átirányítási térképet kell építeni minden megváltozó álnévhez, és olyan description mintákat kell írni, amelyek nem omlanak duplikátumokba. Erre a szakaszra tervezzen az audit díjának egyszeresétől kétszereséig terjedő összeget.

Egy facettás keresést használó, többnyelvű Drupal oldal e sáv fölött van. A brit ügynökségek nagyjából napi £600 és £900 között számláznak Drupal munkát, ahogy a Drupal fejlesztői díjszabásról szóló útmutatónkban leírjuk, és egy több fordítási készlettel meg facettkezeléssel járó munka reálisan tíz-húsz nap.

Kérje kifejezett átadandóként az előtte és utána készült bejárás összevetését. Enélkül semmi nem bizonyítja, hogy bármi tényleg megváltozott.

A helyes sorrend

A működő sorrend nem látványos. Telepítse és állítsa be a négy modult minden más előtt, mert a nélkülük hozott tartalmi döntések később újramunkát szülnek. Ezután zárja be a duplikált URL-ek felületét, mert az az oldal minden lapját érinti. Utána jön a taxonómia és a nézetek kitettsége, aztán a strukturált adat, aztán a teljesítmény. A tartalom és a hivatkozások azután következnek, hogy a technikai réteg stabil, soha nem előtte.

A Mecanik ezt a sorrendet technikai SEO auditként járja végig, amelyet a Drupal kódbázisán és annak konfigurációján futtatunk, nem pusztán egy bejáráson, míg a SEO audit szolgáltatás az ezt követő megvalósítást fedi le. Ha még azt mérlegeli, egyáltalán a Drupal-e a megfelelő platform, a Drupal fejlesztési útmutatónk és a fejnélküli és hagyományos CMS architektúrák összevetése jobb kiindulópont ennél a cikknél.

Gyakran ismételt kérdések

Jó a Drupal SEO szempontjából alapból? Nem. A Drupal magja ad útvonal-álneveket, canonical címkéket és többnyelvű útválasztást, de nem ad meta descriptiont, XML sitemapet, átirányításkezelést és strukturált adatot. Ezekhez a Pathauto, a Metatag, a Simple XML Sitemap és a Redirect modul kell, mindegyik közösségi, nem a mag része. Egy gyári telepítés nem rosszul optimalizált, hanem optimalizálatlan.

Milyen SEO modulokra van valóban szüksége egy Drupal oldalnak? Négy gyakorlatilag kötelező: a Pathauto az automatikus URL-álnevekhez, a Metatag a meta descriptionhöz és a közösségi címkékhez, a Simple XML Sitemap magához a sitemaphez, a Redirect pedig az átirányításokhoz és a kanonikus URL kikényszerítéséhez. A szokásos ötödik a Schema.org Metatag, ha strukturált adatot szeretne anélkül, hogy JSON-LD-t írna kézzel Twig sablonokba.

Miért működik továbbra is a /node/123 az URL-álnév felvétele után? Mert a Drupal álnév nem vonja ki a forgalomból a belső útvonalat. Mindkét cím a teljes oldalt adja vissza 200-as állapottal. A mag canonical címkét ad az álnévre, amelyet a Google erős jelzésként és nem utasításként kezel, így a megbízható megoldás a Redirect modul kanonikus kikényszerítése, amely a duplikátumokat állandó átirányításokká alakítja.

Kompatibilis a Pathauto, a Metatag és a Simple XML Sitemap a Drupal 11 verzióval? Igen, és a négyes alapkészlet mind a négy modulja aktív karbantartás alatt áll. A Pathauto 8.x-1.15 támogatja a Drupal 10.2 és 11 verziót, a Metatag 2.2.0 Drupal 10.3 vagy 11 verziót kér, a Simple XML Sitemap 4.2.3 Drupal 10.3 vagy 11 verziót kér, a Redirect 8.x-1.13 pedig támogatja a Drupal 10 és 11 verziót. Mind a négyre kiterjed a Drupal biztonsági közlemények szabályzata.

Mennyibe kerül egy Drupal SEO munka az Egyesült Királyságban? A modulkészletet, az álnév- és átirányítási táblákat, a taxonómia kitettségét, a sitemapet és a strukturált adatot lefedő konfigurációs audit közepes méretű oldalon három-öt napot vesz igénybe, ami a brit technikai SEO £600 és £1,200 közötti napidíjaival nagyjából £2,000 és £5,000 közé jön ki. A megvalósítás jellemzően az audit díjának egyszeresétől kétszereséig kerül.