Headless WordPress SEO-kockázatai és ellenőrzőlistája

Scheo · 2026-10-27 · olvasási idő ~10 perc · Szerző: Schmidt Péter

Mi az a headless WordPress, és miért érinti közvetlenül az SEO-t?

Headless WordPressnél a WordPress csak tartalomkezelőként fut, a látogató pedig egy külön frontendet lát (például Next.js, Nuxt vagy Astro alapon), amely REST API-n vagy GraphQL-en kéri le a tartalmat. Az SEO azért sérül könnyen, mert addig a WordPress témája és bővítményei gyártották le a HTML fejrészét, és ezt a munkát az új frontendnek kell átvennie.

Egy hagyományos WordPress-oldalon a Yoast SEO vagy a Rank Math beírja a title-t, a meta descriptiont, a canonicalt, az Open Graph címkéket és a JSON-LD strukturált adatot, közben sitemapet generál, az átirányításokat pedig egy Redirection-féle bővítmény kezeli. Leválasztott frontend mellett ezek a beállítások ott maradnak az adatbázisban, csak senki nem írja ki őket a látogatónak és a robotnak. Az admin felület ugyanúgy néz ki, a szerkesztő ugyanúgy kitölti a meta mezőket, és akár hetekig senkinek nem tűnik fel, hogy az élő oldalon üres vagy hibás a fejrész.

Mi szokott elveszni a headless átálláskor?

Leggyakrabban hét dolog tűnik el vagy romlik el csendben. Ezek a SEO-bővítmény meta adatai, a sitemap, a canonical, az átirányítások, a strukturált adat, a szerkesztői előnézet és a szerveroldali renderelés.

A SEO-bővítmény meta adatai

Hivatalosan igazolt. A Yoast SEO a WordPress REST API válaszában yoast_head és yoast_head_json mezőt ad vissza, a Rank Mathben külön headless támogatás kapcsolható be, a WPGraphQL-hez pedig mindkét bővítményhez létezik kiegészítő. Az adat tehát elérhető, de a frontendnek le kell kérnie és ki kell írnia.

Saját tapasztalat. A tipikus hiba, hogy a fejlesztő csak a bejegyzés címét és törzsét kéri le. Ilyenkor a title mindenhol a webhely neve marad, vagy minden aloldalon ugyanaz az alapértelmezett leírás jelenik meg, a szerkesztő által gondosan megírt meta description pedig sehol.

Sitemap

A WordPress az 5.5-ös verzió óta saját sitemapet generál a /wp-sitemap.xml címen, a SEO-bővítmények jellemzően a /sitemap_index.xml címen. Headless felállásban ezek a backend domainjén futnak, és a backend URL-jeit tartalmazzák (például cms.pelda.hu/szolgaltatas/), ami a nyilvános frontenden nem létezik. A frontendnek saját sitemapet kell generálnia a nyilvános URL-ekkel, vagy a backend sitemapjét kell átírva továbbadnia.

Canonical

Ha a frontend egyszerűen átveszi a bővítmény canonical értékét, az a backend domainre mutathat. Ez a legveszélyesebb csendes hiba, mert azt jelzi a Google-nek, hogy az eredeti tartalom egy másik hoszton van. Ugyanilyen gond, ha a backend maga is indexelhető marad, mert akkor ugyanaz a tartalom két domainen él, és a Google választja ki, melyiket tekinti eredetinek.

Átirányítások

A Redirection bővítményben vagy a Rank Math átirányítás-kezelőjében felvett szabályok a WordPress PHP-rétegében futnak le. A frontend kéréseit nem érintik, mert a frontend a WordPresshez csak API-n fordul. Az évek alatt összegyűlt 301-es szabályok így megszűnnek, és a régi, külső oldalakról linkelt URL-ek 404-et adnak. Az átirányításokat a frontend szintjén (például a Next.js redirects beállításában), a CDN-en vagy a webszerveren kell újra felvenni, esetleg a frontendnek kérésenként le kell kérdeznie őket a WordPressből.

Strukturált adat

A bővítmények által generált Schema.org gráf (Organization, WebPage, Article, BreadcrumbList, LocalBusiness) a yoast_head része, vagy külön mezőben érkezik. Ha a frontend sablonja ezt nem teszi be egy <script type="application/ld+json"> blokkba, a strukturált adat eltűnik. Ha pedig a fejlesztő kézzel ír mellé új sémát, könnyen két, egymásnak ellentmondó gráf kerül ugyanarra az oldalra.

Előnézet

A szerkesztő „Előnézet” gombja a WordPress témáját nyitná meg, ami headless rendszerben nincs, vagy nem azt mutatja, amit a látogató lát. Külön előnézeti módot kell építeni (Next.js-ben ez a Draft Mode), amely hitelesítve kéri le a piszkozatot. Ez SEO-kérdés is, mert előnézet nélkül a szerkesztő nem látja, hogyan jelenik meg a cím, a leírás és a kiemelt kép, és a hibák csak élesben derülnek ki. Az előnézeti címeknek noindex fejléccel kell menniük, hogy piszkozat ne kerüljön az indexbe.

Szerveroldali renderelés

Ha a frontend kliensoldali alkalmazásként fut, a szerver egy szinte üres HTML-t küld, és a tartalmat a böngésző JavaScriptje rakja össze. Hivatalosan igazolt. A Google leírása szerint a Googlebot rendereli a JavaScriptet, de a renderelés a feltérképezés után, külön sorban állva történik, és hibázhat, ha egy API-hívás lassú vagy elszáll. A Google a dinamikus renderelést kerülőmegoldásnak nevezi, és szerveroldali renderelést, statikus generálást vagy hidratálást ajánl helyette.

Hogyan látja a Google és az AI-crawler a leválasztott frontendet?

A Google jó eséllyel látja a JavaScripttel betöltött tartalmat is, csak később és nagyobb hibalehetőséggel. Az AI-crawlerekről ezt nem érdemes feltételezni, ezért a fontos tartalomnak és a meta adatoknak a szerver által küldött HTML-ben kell lenniük.

Szakmai feltételezés. Az OpenAI, az Anthropic és a Perplexity dokumentálja a robotjai nevét (GPTBot, OAI-SearchBot, ClaudeBot, PerplexityBot) és a robots.txt kezelését, de nyilvánosan nem állítja, hogy ezek a robotok JavaScriptet futtatnának. Független naplóelemzések alapján jellemzően a nyers HTML-t olvassák. Ezt munkahipotézisként érdemes kezelni, amíg a gyártók mást nem dokumentálnak.

Saját tapasztalat. Kliensoldalon renderelt oldalaknál a szervernaplóban az AI-robotok kérései rendben, 200-as kóddal futnak le, miközben a kapott HTML-ben csak egy üres div és néhány script-hivatkozás van. A naplóból úgy tűnik, minden működik, a robot mégsem kapott érdemi szöveget. Ezért a státuszkód mellett a válasz méretét és tartalmát is ellenőrizni kell.

Mit kell a headless frontendnek külön megvalósítania?

A frontendnek mindent ki kell írnia, amit korábban a téma és a SEO-bővítmény adott, és mindezt a szerver által küldött HTML-ben. Az alábbi lista indulás előtti átadási feltételnek is használható.

1. Szerveroldali vagy statikus renderelés minden indexelendő oldaltípusra (főoldal, aloldal, kategória, cikk, termék), a teljes törzsszöveggel.
2. Title és meta description oldalanként a SEO-bővítmény mezőiből, üres mező esetén értelmes tartalékkal.
3. Canonical a nyilvános domainre átírva, önmagára mutatva, a záró perjel és a kisbetűs írás szabálya szerint egységesen.
4. Robots meta átvétele, hogy a WordPressben noindexre tett oldal a frontenden is noindex legyen.
5. Open Graph és X-címkék a megosztási előnézethez, abszolút képútvonallal.
6. JSON-LD strukturált adat egyetlen, ellentmondásmentes gráfban, a nyilvános URL-ekkel.
7. Sitemap a nyilvános URL-ekkel, valós lastmod dátummal, beküldve a Search Console-ba.
8. robots.txt a frontend domainjén, a sitemap hivatkozásával, és az AI-crawlerekre hozott döntésed szerint.
9. Átirányítások 301-es kóddal a frontend vagy a CDN szintjén, a régi szabálylista teljes átvételével.
10. Valódi 404-es és 410-es státuszkód a nem létező oldalakra. Kliensoldali alkalmazásban gyakori, hogy a „nem található” oldal 200-as kóddal megy ki, ezt a Google soft 404-nek tekinti.
11. Belső linkek valódi <a href> elemként, mert a Google a kattintásra futó JavaScript-navigációt nem követi linkként.
12. Képek alt szöveggel a médiatárból, méretezve, a hajtás feletti képnél lusta betöltés nélkül.
13. hreflang, ha többnyelvű az oldal, a WPML vagy a Polylang adatából.
14. A backend elzárása, vagyis a cms aldomain noindex fejléccel vagy jelszóval védve.
15. Előnézeti mód a szerkesztőknek, hitelesítve és noindex fejléccel.
16. Újraépítés vagy gyorsítótár-ürítés mentéskor, hogy statikus generálásnál a módosított meta adat ne napokkal később jelenjen meg.

Egy egyszerű példa a canonical átírására Next.js App Routerben, a generateMetadata függvényen belül, a Yoast-adatból. A CMS_URL a backend, a SITE_URL a nyilvános domain címe.

const canonical = yoast.canonical.replace(CMS_URL, SITE_URL);

const { title, description } = yoast;

const alternates = { canonical };

return { title, description, alternates };

Saját tapasztalat. A domaincsere ritkán áll meg a canonicalnál. A backend címe ott marad az og:url mezőben, a JSON-LD gráf @id és url értékeiben, a breadcrumb elemeiben, sőt a bejegyzések törzsében is, ahol a szerkesztő belső linket tett be. Érdemes egyetlen központi függvényt írni, amely minden kimenő URL-t átír, és egy tesztet, amely jelez, ha a renderelt HTML-ben bárhol megjelenik a backend domain.

Hogyan teszteld a renderelt kimenetet a Google és az AI-crawlerek szemszögéből?

Két nézetet kell összevetni. A nyers HTML azt mutatja, amit egy JavaScriptet nem futtató robot lát, a renderelt DOM pedig azt, amit a Google a renderelés után. Ha a kettő lényegesen eltér, az AI-crawlerek jó eséllyel a szegényebb változatot kapják.

1. Nyers HTML lekérése. Parancssorból például így curl -s -A "GPTBot" https://pelda.hu/szolgaltatas/ | grep -iE "<title|canonical|description|ld\+json". Ha a title, a canonical és a JSON-LD nem jön vissza, a robot sem kapja meg őket. Keress rá a törzsszöveg egy egyedi mondatára is.
2. Ugyanez több user-agenttel. Futtasd Googlebot, ClaudeBot és hétköznapi böngésző azonosítóval is, és vesd össze a válaszok méretét. Eltérésnél valamelyik réteg (CDN, bot-védelem, tűzfal) mást ad a robotoknak.
3. Search Console URL-ellenőrzés. Az élő teszt megmutatja a renderelt HTML-t, a képernyőképet, a betöltött erőforrásokat és a JavaScript-hibákat. Itt derül ki, ha egy API-hívás a Googlebotnál időtúllépéssel elszáll.
4. Rich Results Test és Schema Markup Validator. Ezek a renderelt oldalt is figyelembe veszik, ezért a strukturált adatnál az első lépés szerint a nyers HTML-t is nézd meg.
5. Feltérképezés JavaScript nélkül és JavaScripttel. Egy crawler (például Screaming Frog) két futása oldaltípusonként megmutatja, hol hiányzik a title, a canonical vagy a belső link a nyers HTML-ből.
6. Átirányítások tömeges ellenőrzése. A régi szabálylista minden sorára 301-es választ és helyes célt várj, átirányítási lánc nélkül.
7. Státuszkódok. Kérj le egy biztosan nem létező URL-t, és ellenőrizd, hogy valóban 404 jön-e vissza.
8. Szervernapló. Az indulás utáni hetekben figyeld, mely robotok milyen URL-eket kérnek, és mekkora választ kapnak.

Hogyan készítsd elő az átállást, hogy mérhető legyen a különbség?

Az átállás előtt rögzítsd a régi oldal teljes SEO-állapotát, és az új frontendet ehhez mérd URL-enként. Így nem utólag, a forgalomcsökkenésből derül ki, mi veszett el.

1. Térképezd fel a régi oldalt, és mentsd el minden URL title-jét, descriptionjét, canonicalját, státuszkódját és strukturált adatát.
2. Exportáld a Redirection vagy a Rank Math átirányításait, a Search Console-ból pedig a legtöbb kattintást és külső linket kapó oldalakat.
3. Az új frontendet egy elzárt staging címen ugyanazzal a crawlerrel futtasd végig, és vesd össze a két táblát URL-enként.
4. Csak akkor válts, ha az eltérések listája üres, vagy minden eltérés tudatos döntés.
5. Indulás után kövesd a Search Console indexelési jelentését, a 404-es hibákat és a fontos oldalak kattintásait.

Melyik KKV-helyzetben nem éri meg a headless WordPress?

Saját tapasztalat. Egy tipikus KKV-oldalnál a headless architektúra ritkán hoz annyi előnyt, amennyi többletmunkát és kockázatot jelent. Különösen akkor nem éri meg, ha nincs állandó fejlesztő, aki a frontendet karbantartja.

• Kis bemutatkozó oldal néhány tucat aloldallal, ahol a sebességet egy jó téma, gyorsítótár és képoptimalizálás is rendbe teszi.
• Nincs saját vagy szerződött fejlesztő. Minden új mező, oldaltípus és bővítményfrissítés fejlesztői munka lesz, és ha a fejlesztő elérhetetlenné válik, a cég olyan rendszerrel marad, amelyet más nehezen vesz át.
• A csapat vizuális szerkesztővel dolgozik. Az Elementorral épített elrendezések nem kerülnek át maguktól a headless frontendre, és a szerkesztő elveszíti a vizuális szabadságot.
• WooCommerce-bolt sok bővítménnyel. A fizetési, szállítási, kupon- és értékelés-bővítmények jó része a téma rétegére épül, ezeket egyenként újra kell építeni.
• Bővítményekre épülő marketingeszközök. Az űrlapok, a sütikezelés, a mérőkódok és az A/B tesztek mind külön integrációt kérnek.

Akkor lehet indokolt, ha ugyanazt a tartalmat több csatornára kell eljuttatni (weboldal, mobilalkalmazás, kioszk), ha a frontendet amúgy is egy fejlesztőcsapat építi és tartja karban, vagy ha a sebességi és biztonsági követelmény hagyományos WordPress-szel nehezen teljesíthető.

Szakmai feltételezés. A headless átállás önmagában nem javítja a helyezéseket. A gyorsabb betöltés segítheti a felhasználói élményt, de egy hiányosan átvitt meta- és átirányításkészlet többet ronthat a láthatóságon, mint amennyit a sebesség hoz.

Források és további olvasnivalók

• Google Search Central, A JavaScript SEO alapjai
• Google Search Central, Dinamikus renderelés mint kerülőmegoldás
• Google Search Central, Kanonikus URL-ek megadása
• Google Search Central, Átirányítások és a Google Kereső
• Google Search Console súgó, URL-ellenőrző eszköz
• Schema.org dokumentáció
• OpenAI dokumentáció, Overview of OpenAI Crawlers
• Anthropic súgó, ClaudeBot és a robots.txt
• WordPress Developer Resources, REST API Handbook
• Yoast fejlesztői dokumentáció, REST API
• Next.js dokumentáció, Metadata, Redirects és Draft Mode
• W3C és WHATWG, HTML-specifikáció