WordPress-sablonváltás SEO-ellenőrzőlistája

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

A WordPress-sablon cseréje sokszor egy délutános feladatnak tűnik. Feltöltöd az új témát, aktiválod, rendbe teszed a menüt, és az oldal szebb lesz. A keresőoptimalizálás felől nézve viszont a téma sokkal többet csinál annál, ami a szemnek látszik. Ő írja ki a címsorokat, gyakran ő rakja össze a morzsamenüt, ő dönti el, mely egyedi mezők kerülnek a HTML-be, és ő regisztrálja a képméreteket. Ha ezek közül valami csendben elmarad, az oldal ugyanúgy betölt, csak a keresők és az AI-válaszmotorok mást látnak belőle, mint korábban.

Ez az ellenőrzőlista arra az esetre szól, amikor a domain, az URL-szerkezet és a tartalom marad, és csak a megjelenítésért felelős téma cserélődik. A szövegben külön jelölöm, mi hivatalosan igazolt (Google Search Central, WordPress- és WP-CLI-dokumentáció), mi saját tapasztalat, és mi szakmai feltételezés.

Miben különbözik a sablonváltás az újratervezéstől és a domainváltástól?

Röviden. Sablonváltásnál a domain, az URL-ek és a tartalom változatlan, csak a HTML-kimenet és a megjelenés módosul. Újratervezésnél jellemzően a tartalom és az oldalszerkezet is átalakul, domainváltásnál pedig minden URL új címre költözik, átirányításokkal.

Hivatalosan igazolt. A Google Search Central az oldalköltöztetést URL-változással járó folyamatként írja le, amelyhez átirányítási térkép és a Search Console címváltoztatási eszköze tartozik. Tiszta témacserénél egyik sem kell, mert egyetlen URL sem változik. Ha mégis változik, például mert az új téma más archívum-útvonalat vagy saját egyedi bejegyzéstípust hoz, akkor a projekt már részben költözés, és úgy is kell kezelni.

Saját tapasztalat. A legtöbb gond abból fakad, hogy a témacserét csak dizájnmunkaként kezelik, ezért senki nem rögzíti előtte az állapotot. Amikor pár héttel később visszaesik egy oldaltípus forgalma, már nincs mihez hasonlítani.

Mi tűnhet el észrevétlenül egy témaváltáskor?

Röviden. Leggyakrabban a címsor-hierarchia, a morzsamenü, a téma által kiírt strukturált adat, az egyedi mezők megjelenítése, a widgetekben ülő belső linkek, az archívumoldalak beállításai és a regisztrált képméretek. Ezek az adatbázisban többnyire megmaradnak, csak az új téma nem jeleníti meg őket.

Címsorstruktúra

Az egyik téma a bejegyzés címét H1-be teszi, a másik H2-be, a harmadik a logót is H1-ként írja ki minden oldalon. Előfordul, hogy az oldalsáv widgetcímei H2-ként jelennek meg, és a tartalom tagolása így összekeveredik a sablonelemekkel. Szakmai feltételezés. Egy H1-gyel több vagy kevesebb önmagában ritkán okoz érzékelhető rangsorváltozást. A válaszmotorok viszont a címsorok mentén darabolják a szöveget, így a tiszta hierarchia jó eséllyel segíti, hogy egy szakaszt pontosan idézzenek.

Morzsamenü

A morzsamenüt adhatja a téma, a SEO-bővítmény vagy egy oldalépítő modul. Ha a régi téma írta ki, az új téma alatt egyszerűen eltűnik, és vele együtt a BreadcrumbList jelölés is. Nézd meg, honnan jön ma a morzsamenü, és döntsd el, az új környezetben melyik elem fogja kiírni.

Strukturált adat

Sok téma saját maga ír ki schema-jelölést (Article, WebPage, Organization, néha elavult microdata formában). Ha a SEO-bővítményed is ír, a váltás után duplikált vagy épp hiányzó jelölés maradhat. Hivatalosan igazolt. A Google strukturált adatokra vonatkozó irányelvei szerint a jelölésnek az oldalon látható tartalmat kell tükröznie. Ha tehát az új téma elrejti a szerzőt, a dátumot vagy a GYIK-blokkot, a jelölésben szereplő adat elveszíti a látható megfelelőjét.

Egyedi mezők

Az ACF-hez hasonló bővítményekkel létrehozott mezők az adatbázis wp_postmeta táblájában maradnak, a megjelenítésüket viszont a téma sablonfájljai végzik. Ha a régi téma egyedi template-je írta ki a nyitvatartást, a műszaki adatokat vagy a GYIK-et, az új témában ez a szöveg egyik napról a másikra hiányzik a HTML-ből. A tartalom az adminban megvan, a kereső mégsem látja.

Widgetekben lévő belső linkek

A widget-területek témához kötöttek. Témaváltáskor a WordPress megpróbálja megfeleltetni a régi és az új területeket, és ami nem talál párt, az az Inaktív widgetek közé kerül. Ha a kapcsolódó szolgáltatásokra vagy a kiemelt cikkekre mutató linkek widgetben voltak, az oldalak belső linkjeinek száma egy csapásra csökkenhet. Saját tapasztalat. Ez a leggyakoribb rejtett veszteség, mert vizuálisan az új oldal letisztultabbnak hat, és senki nem hiányolja az oldalsávot.

Archívumoldalak és a téma saját beállításai

A kategória-, címke-, szerző- és dátumarchívumok indexelését többnyire a SEO-bővítmény kezeli, de néhány téma saját kapcsolókat hoz, például a kivonat vagy a teljes szöveg megjelenítésére, a lapozásra vagy a kategórialeírás kiírására. Ha a régi téma kiírta a kategórialeírást, az új pedig nem, az archívumoldal vékony listává válik. A Customizer beállításai témánként külön tárolódnak, ezért a régi téma beállításai nem öröklődnek, és a menühelyeket is újra kell rendelni.

Képméretek

Minden téma saját képméreteket regisztrál az add_image_size() függvénnyel. A korábbi feltöltésekhez ezek a vágatok nem készülnek el maguktól, ezért az új téma gyakran a teljes méretű eredetit tölti be, vagy rossz arányú képet mutat. Ez ronthatja a Largest Contentful Paint értékét, a hiányzó width és height attribútum pedig elmozduló elrendezést (CLS) okozhat.

Hogyan készítsd elő a váltást mentéssel és staging-környezettel?

Röviden. Teljes mentés a fájlokról és az adatbázisról, jelszóval védett staging-másolat, a téma beállítása és mérése ott, és csak az összevetés után élesítés. Élő oldalon témát próbálgatni a legkockázatosabb út.

1. Készíts teljes mentést a fájlokról és az adatbázisról, és próbáld ki, hogy visszaállítható. Egy soha ki nem próbált mentés inkább remény.
2. Hozz létre staging-másolatot, védd jelszóval, és kapcsold ki rajta a keresők számára a láthatóságot.
3. Rögzítsd a régi téma beállításait, widgetjeit és menühelyeit fájlba.
4. Telepítsd az új témát gyermektémával együtt, hogy a saját módosításaid egy frissítés után is megmaradjanak.
5. Pótold a sablonfájlokban az egyedi mezők kiírását, a morzsamenüt és a widgetek tartalmát.
6. Generáld újra a képvágatokat.
7. Futtasd le a feltérképezést és a teljesítménymérést a stagingen.

WP-CLI-val a mentés és a régi állapot rögzítése néhány parancs. A regitema helyére a régi téma könyvtárnevét írd, a sidebar-1 helyére a saját widget-területed azonosítóját.

wp db export elotte-temavaltas.sql

wp option get theme_mods_regitema --format=json > regitema-beallitasok.json

wp widget list sidebar-1 --format=csv > widgetek-sidebar-1.csv

wp menu location list

A stagingen ezután kikapcsolod a láthatóságot, az új téma aktiválása után pedig pótolod a hiányzó képvágatokat.

wp option update blog_public 0

wp theme activate ujtema-child

wp media regenerate --only-missing --yes

Hivatalosan igazolt. A WordPress fejlesztői dokumentációja szerint a Customizer-beállítások a theme_mods_{témanév} opcióban, témánként külön tárolódnak, a fenti parancsokat pedig a WP-CLI dokumentációja írja le. A blog_public kikapcsolása csak kérés a keresők felé, ezért a stagingen a jelszavas védelem a megbízhatóbb zár.

Mit rögzíts előtte-állapotként?

Röviden. Egy teljes feltérképezést az élő oldalról, a Search Console teljesítmény- és Core Web Vitals-adatait, valamint oldaltípusonként néhány minta-URL forráskódját és strukturált adatát. Ezek nélkül a váltás utáni változásokat nem tudod megbízhatóan értelmezni.

• Feltérképezés exportja (például Screaming Frog vagy Sitebulb) a title, a meta description, a H1 és H2 darabszám, a canonical, a státuszkód, a szószám, a bejövő és kimenő belső linkek száma és a strukturált adat típusai mezőkkel.
• Oldaltípusonként egy-egy minta-URL mentett HTML-je (főoldal, szolgáltatásoldal, blogbejegyzés, kategóriaarchívum, termékoldal, ha van).
• A Rich Results Test és a Schema Markup Validator eredménye ugyanezekre az URL-ekre.
• Search Console teljesítményexport oldalakra és lekérdezésekre, legalább három hónapra visszamenőleg.
• A Core Web Vitals-jelentés állapota és PageSpeed Insights-mérés a minta-URL-ekre, mobilon és asztali nézetben külön.

Saját tapasztalat. Érdemes a feltérképezést egyéni kinyeréssel (custom extraction) kiegészíteni, amely kigyűjti a morzsamenü szövegét és az egyedi mezők blokkjait egy-egy CSS-szelektor vagy XPath alapján. Így az összevetésnél azonnal látszik, melyik oldalról tűnt el.

Hogyan vesd össze az előtte és utána készült feltérképezést?

Röviden. Ugyanazzal a beállítással futtasd le a feltérképezést a stagingen az új témával, majd URL-enként vesd össze a két exportot. Az eltérések listája lesz a javítandó tételek listája.

Táblázatkezelőben az URL alapján egymás mellé teszed a két exportot, és oszloponként különbséget számolsz. Ezekre az eltérésekre figyelj a legjobban.

• A H1 hiányzik, megduplázódott, vagy más szöveg került bele.
• A bejövő belső linkek száma érezhetően csökkent, ami többnyire widget- vagy láblécmenü-veszteséget jelez.
• A szószám feltűnően visszaesett, mert egy egyedi mező vagy blokk nem jelenik meg.
• A title, a meta description vagy a canonical megváltozott, mert a téma saját SEO-funkciója felülírja a bővítményt.
• Új URL-ek bukkannak fel, például csatolmányoldalak vagy a téma saját portfólió-archívuma.
• A strukturált adat típusai eltérnek, vagy egy típus kétszer szerepel.
• A képek fájlmérete megnőtt, mert a téma a teljes méretű eredetit tölti be.

Hogyan értelmezd a Core Web Vitals-adatokat a váltás után?

Röviden. A laborméréseken (PageSpeed Insights, Lighthouse) a változás azonnal látszik, a mezőadatok (Chrome UX Report, Search Console) viszont 28 napos gördülő ablakot használnak, ezért a valós felhasználói hatás csak hetekkel később áll össze.

Hivatalosan igazolt. A három mutató az LCP (Largest Contentful Paint), az INP (Interaction to Next Paint, amely 2024 márciusában váltotta az FID-et) és a CLS (Cumulative Layout Shift). A jó tartomány határa LCP-nél 2,5 másodperc, INP-nél 200 milliszekundum, CLS-nél 0,1, a látogatások 75. percentilisén mérve.

Szakmai feltételezés. A Core Web Vitals az oldalélmény egyik jele, a tartalom relevanciájához képest kisebb súllyal. Egy témaváltás utáni forgalomváltozás okát ezért először a tartalmi és szerkezeti eltérések között keresd, a teljesítményt pedig a látogatók miatt tartsd rendben.

Saját tapasztalat. A sok funkciót egyben hozó témák gyakran nehezebbek a régi, egyszerű sablonnál, főleg a betöltött szkriptek és betűkészletek miatt. Ha a stagingen romlik az LCP vagy az INP, élesítés előtt kapcsold ki a nem használt modulokat, és nézd meg, hány betűkészletet és milyen súlyú JavaScriptet tölt be az új téma.

Mi legyen az élesítés napjának menete?

Röviden. Friss mentés, alacsony forgalmú időpont, aktiválás, a stagingen előkészített beállítások átvitele, gyorsítótár ürítése, majd azonnali ellenőrzés a minta-URL-eken.

1. Készíts friss mentést az élő oldalról közvetlenül a váltás előtt.
2. Aktiváld az új témát és a gyermektémát, állítsd be a menühelyeket és a widgeteket a staging alapján.
3. Generáld újra a hiányzó képvágatokat.
4. Ürítsd a gyorsítótárat és a CDN-t.
5. Nézd meg a minta-URL-ek forráskódjában a title-t, a H1-et, a canonicalt, a robots meta címkét és a strukturált adatot.
6. Ellenőrizd, hogy a keresők számára a láthatóság be van kapcsolva, mert a stagingről átvitt adatbázissal a blog_public 0 értéke is átjöhet.
7. Futtass rövid feltérképezést az élő oldalon, és vesd össze a stagingen kapott eredménnyel.

Saját tapasztalat. A legsúlyosabb, mégis visszatérő hiba, hogy a staging teljes adatbázisát másolják vissza élesre, és vele a noindex-beállítás is átkerül. Ez egy perc alatt kiderül, ha az élesítés után megnézed a főoldal forrásában a robots meta címkét.

Mit figyelj a váltás utáni hetekben?

Röviden. Az első két hétben a Search Console indexelési jelentését, a bővített találatok jelentéseit és a feltérképezési hibákat, utána a teljesítményt oldaltípusonként, legalább négy-hat hétig.

• Az Oldalak jelentésben az új, noindex miatt kizárt vagy feltérképezett, de nem indexelt tételek.
• A bővített találatok jelentései (morzsamenü, termék, GYIK, ha volt). Ha a számuk csökken, a jelölés tűnt el.
• A teljesítmény oldaltípusonként, ugyanannyi nappal a váltás előtt és után, a váltás dátumát megjelölve.
• A Core Web Vitals-jelentés a 28 napos ablak letelte után.
• A 404-es hibák a szervernaplóban, ha a téma más csatolmány- vagy archívumútvonalat használ.

Szakmai feltételezés. Egy gondosan elvégzett témacsere után a helyezések jó eséllyel stabilak maradnak, mivel a tartalom és az URL-ek nem változtak. Pár napos ingadozás előfordulhat, amíg a Google újra feltérképezi az oldalakat, ezért a döntéseidet a több hetes adatokra építsd.

Hogyan néz ki a teljes ellenőrzőlista egyben?

Röviden. A váltás előtt rögzítesz és mentesz, a stagingen pótolsz és mérsz, élesítés után pedig összevetsz és figyelsz.

Előtte

• Teljes, kipróbált mentés a fájlokról és az adatbázisról.
• Feltérképezés egyéni kinyeréssel a morzsamenüre és az egyedi mezőkre.
• A régi téma beállításainak, widgetjeinek és menühelyeinek exportja.
• Search Console- és Core Web Vitals-alapadatok, minta-URL-ek HTML-je és strukturáltadat-tesztje.

Stagingen

• Címsor-hierarchia oldaltípusonként.
• Morzsamenü és BreadcrumbList jelölés.
• Strukturált adat duplikáció és hiány nélkül.
• Egyedi mezők kiírása a sablonfájlokban.
• Widgetekben lévő belső linkek áthelyezése.
• Archívumoldalak beállításai és a kategórialeírások.
• Képvágatok újragenerálása, width és height attribútumok.
• Laborméréses LCP, INP és CLS a minta-URL-eken.

Utána

• Robots meta és blog_public ellenőrzése élesen.
• Feltérképezés és összevetés az előtte-állapottal.
• Search Console indexelési és bővítettalálat-jelentések két hétig.
• Teljesítmény és Core Web Vitals-mezőadatok négy-hat hétig.

Források és további olvasnivalók

• Google Search Central, Site moves with URL changes
• Google Search Central, General structured data guidelines
• Google Search Central, Understanding Core Web Vitals and Google search results
• web.dev, Core Web Vitals (LCP, INP, CLS)
• Chrome UX Report dokumentáció
• WordPress Developer Resources, Theme Handbook és Theme Modification API
• WordPress Developer Resources, add_image_size()
• WP-CLI Commands dokumentáció
• Schema.org, BreadcrumbList
• W3C, HTML Living Standard (címsorelemek)