Belső linkek frissítése migráció után adatbázis-szintű kereséssel és cserével

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

Domainváltás, HTTPS-re állás vagy új URL-szerkezet után szinte mindig az átirányítások beállítása az első teendő. Ez jó lépés, de a munkának csak az egyik fele. A régi címek ott maradnak a bejegyzések szövegében, a menükben, a lábléc widgetjeiben és az oldalépítő által tárolt adatokban. Ez a cikk végigmegy azon, miért érdemes ezeket adatbázis-szinten lecserélni, hogyan csináld WP-CLI-vel vagy bővítménnyel, mire figyelj a szerializált adatoknál, és hogyan nézd meg feltérképezéssel, hogy tényleg nem maradt átirányításra mutató belső link.

A szövegben jelölöm, mi a hivatalosan igazolt információ (dokumentációból), mi a saját tapasztalat, és mi a szakmai feltételezés.

Miért nem elég az átirányítás egy migráció után?

Az átirányítás a külső hivatkozásokat és a régi könyvjelzőket menti meg, a saját belső linkjeidet viszont neked kell frissítened. Ha a belső hivatkozások a régi címre mutatnak, minden kattintás és minden robotlátogatás egy felesleges plusz kérést fut, és az oldal jelei megoszlanak a régi és az új URL között.

Hivatalosan igazolt: a Google Search Central URL-változással járó webhely-költöztetésről szóló útmutatója külön lépésként írja elő a belső linkek frissítését, hogy azok egyenesen az új címekre mutassanak. A Google dokumentációja szerint a Googlebot egy átirányítási láncban legfeljebb tíz ugrást követ, és a láncokat a felhasználó és a feltérképezés szempontjából is kerülendőnek tartja.

Saját tapasztalat: migráció után a régi linkek nagy része általában nem a bejegyzések törzsszövegében marad, mert ott valaki jó eséllyel észreveszi és lecseréli őket. Legtöbbször a lábléc szöveges widgetjei, az egyedi menüpontok, az oldalépítő gombjai és az űrlapok küldés utáni átirányításai maradnak ki. Ezeket egyenként végigkeresni órákig tart, és szinte biztos, hogy valami kimarad.

Szakmai feltételezés: az AI-alapú keresők és válaszmotorok robotjai valószínűleg kisebb feltérképezési kerettel dolgoznak, mint a Googlebot. Ezért úgy gondoljuk, hogy az átirányítás nélküli belső linkszerkezet nekik is könnyebbé teszi az oldalak felfedezését, de erről nincs nyilvános, mért adat.

Hol maradnak régi linkek egy WordPress-oldal adatbázisában?

A régi URL-ek jellemzően négy helyen ragadnak bent: a bejegyzések tartalmában, a metaadatokban, a beállításokban és a bővítmények saját tábláiban. Ha csak a szerkesztőfelületen keresel, ezek közül legfeljebb az elsőt látod.

• wp_posts: a post_content és a post_excerpt mezőkben lévő linkek és beágyazott képek.
• wp_postmeta: az oldalépítők adatai (Elementornál JSON-ként a _elementor_data kulcs alatt), az ACF-mezők, a SEO-bővítmények egyedi canonical beállításai és az egyedi menüpontok _menu_item_url értéke.
• wp_options: a widgetek, a téma beállításai (theme_mods_), a siteurl és a home, valamint sok bővítmény konfigurációja, többnyire szerializálva.
• wp_termmeta és wp_usermeta: a kategórialeírások és a szerzői profilok linkjei.
• Bővítménytáblák: az űrlapkezelők, a webshop-beállítások és a felugró ablakok.
• Fájlok: a téma sablonjaiba vagy a CSS-be beégetett abszolút URL-ek, amelyeket semmilyen adatbázis-csere nem ér el.

Mi a szerializált adatok csapdája?

A PHP szerializált formátuma minden szöveg mellett annak hosszát is eltárolja. Ha sima SQL REPLACE paranccsal cseréled a domaint, a tárolt hossz nem egyezik a szöveggel, és a WordPress olvashatatlannak tekinti az egész beállítást. Ilyenkor eltűnhet egy widget, kiürülhet a téma testreszabása, vagy alapállapotba kerülhet egy bővítmény.

Egy egyszerű példa a wp_options táblából:

a:1:{s:3:"url";s:21:"http://regi-domain.hu";}

Ha ezt https://uj-domain.hu címre cseréled, a szöveg 20 karakteres lesz, a tárolt érték viszont továbbra is 21-et mond. A PHP unserialize() függvénye ilyenkor hibát ad, és a WordPress üres értékkel dolgozik tovább. Hivatalosan igazolt: a WP-CLI dokumentációja szerint a search-replace parancs felismeri a szerializált PHP-adatot, kibontja, elvégzi a cserét, majd helyes hosszal szerializálja újra. A Better Search Replace bővítmény leírása ugyanezt mondja magáról.

Van egy második csapda is. Az Elementor és több más oldalépítő JSON-ban tárolja az adatokat, és ott a perjelek escape-elve szerepelnek, például így: https:\/\/regi-domain.hu. A sima https://regi-domain.hu keresés ezeket nem találja meg, ezért ezt az alakot külön is cserélni kell. Az Elementor saját URL-csere eszköze (Eszközök menü) csak az Elementor adatain dolgozik, a többi táblát nem nézi. Saját tapasztalat: az Elementoros oldalakon a migráció után megmaradt régi linkek jelentős része pont ebben az alakban van.

Miért kötelező a mentés, és hogyan készítsd el?

Az adatbázis-szintű csere egyetlen lépésben akár több ezer sort ír át, és nincs visszavonás gomb. Ezért futtatás előtt mindig készíts teljes adatbázis-mentést, és győződj meg róla, hogy vissza is tudod tölteni.

1. Exportáld az adatbázist WP-CLI-vel: wp db export mentes-csere-elott.sql
2. Ellenőrizd, hogy a fájl nem üres, és a mérete arányban áll az oldal tartalmával.
3. Ha a tárhely is készít mentést, indíts ott is egy kézi mentést, így két független példányod lesz.
4. Nagyobb oldalon a cserét először egy staging-másolaton futtasd, és csak sikeres ellenőrzés után élesben.
5. Ha vissza kell állnod: wp db import mentes-csere-elott.sql

Hogyan futtasd biztonságosan a WP-CLI search-replace parancsot?

A biztonságos sorrend a próbafuttatás, az ellenőrzés és az éles csere, a régi cím minden változatára külön, a legpontosabb alakkal kezdve. A --dry-run kapcsolóval a parancs megmutatja, táblánként hány előfordulást cserélne, de semmit nem ír át.

1. Nézd meg, mi van az adatbázisban: wp db search 'regi-domain.hu' --all-tables
2. Próbafuttatás: wp search-replace 'https://www.regi-domain.hu' 'https://uj-domain.hu' --all-tables-with-prefix --skip-columns=guid --dry-run --report-changed-only
3. Ha a számok reálisak, futtasd le ugyanezt a --dry-run kapcsoló nélkül.
4. Ismételd meg a többi változattal: http://www., majd https:// és http:// www nélkül.
5. Futtasd le a JSON-escape-elt alakra is: wp search-replace 'https:\/\/www.regi-domain.hu' 'https:\/\/uj-domain.hu' --all-tables-with-prefix --skip-columns=guid --dry-run
6. Ürítsd a gyorsítótárat (wp cache flush), a cache-bővítményét és a CDN-ét is, Elementornál pedig generáld újra a CSS-t az Eszközök menüben.

A www-s változattal azért érdemes kezdeni, mert ha előbb a csupasz regi-domain.hu alakot cserélnéd, a www.regi-domain.hu címből www.uj-domain.hu lenne. Ha az új oldal www nélkül fut, ezzel újabb átirányítást gyártanál. A protokollal együtt megadott teljes cím cseréje kiszámíthatóbb. Ugyanezért kerüld a csupasz domain cseréjét, mert az info@regi-domain.hu e-mail-cím is megváltozna, és ez nem mindig kívánatos.

Hivatalosan igazolt: a WordPress dokumentációja a webhely címének megváltoztatásáról kifejezetten óv a guid oszlop átírásától, ezért szerepel a parancsban a --skip-columns=guid. A --precise kapcsolóval minden csere PHP-ben fut SQL helyett. Ez lassabb, de biztosabb, ha vegyes adatokkal dolgozol. Multisite hálózatnál a --network kapcsolóra, valamint a wp_blogs és a wp_site táblára külön figyelj.

Mikor jó választás a Better Search Replace jellegű bővítmény?

Akkor, ha nincs SSH-hozzáférésed, vagy kisebb oldalon dolgozol, és a grafikus felület gyorsabb. Ezekben a bővítményekben kiválaszthatod a táblákat, van próbafuttatás, és kezelik a szerializált adatot.

• Az első futtatás mindig próbafuttatás legyen, és nézd meg a táblánkénti találatszámot.
• A guid oszlop cseréjét kapcsold ki, ha a bővítmény felkínálja ezt a lehetőséget.
• A JSON-escape-elt alakot itt is külön kell megadnod.
• Nagy táblánál a böngészőből indított futás időkorlátba ütközhet. A bővítmény ilyenkor kötegekben dolgozik, de ha megszakad, nézd meg, hol állt meg.
• A munka végén kapcsold ki és töröld a bővítményt, mert egy adatbázist átíró eszközt felesleges élesen hagyni.

Saját tapasztalat: néhány száz oldalas webhelyen a bővítmény jól használható, a több tízezer bejegyzéses webshopokon viszont a WP-CLI gyorsabb és kiszámíthatóbb.

Mit keress pontosan? Ellenőrzőlista a cseréhez

Keresd meg a régi cím minden leírt formáját, mert az adatbázis csak a betűre pontos egyezést találja meg.

• http://regi-domain.hu és https://regi-domain.hu
• http://www.regi-domain.hu és https://www.regi-domain.hu
• Protokoll nélküli hivatkozás, például //regi-domain.hu
• JSON-escape-elt alak, például https:\/\/regi-domain.hu
• URL-kódolt alak, ezt egyes bővítmények így tárolják: https%3A%2F%2Fregi-domain.hu
• Staging- és fejlesztői címek, például staging.uj-domain.hu, uj-domain.local, illetve a tárhely ideiglenes címe vagy IP-címe
• Régi slugok és útvonalak, például egy átnevezett kategóriaalap (/termekkategoria/), a régi permalink-szerkezet (/?p=123, /index.php/) vagy a dátumos útvonalak
• A régi feltöltési útvonal, ha a médiatár is költözött (/wp-content/uploads/sites/2/)
• HTTPS-váltásnál a saját domain http:// alakja a képeknél és a szkripteknél is, mert ebből vegyes tartalom figyelmeztetés lesz

Slugváltásnál légy óvatos. Egy rövid, általános slug (például /blog/) olyan helyeken is egyezést találhat, ahol nem link áll. Ilyenkor a teljes URL-re keress, a domainnel együtt.

Mit ne cserélj le az adatbázisban?

Az átirányítási szabályokat tároló táblákat, a guid oszlopot és a naplótáblákat hagyd ki a cseréből. WP-CLI-ben erre a --skip-tables kapcsoló szolgál.

• Az átirányító bővítmény táblái (például a Redirection bővítményé). Ha a forrás URL-eket is az új címre írod át, a szabály önmagára mutat, és átirányítási hurok keletkezhet.
• A guid oszlop. Ez belső azonosító, a hírcsatorna-olvasók ehhez kötik a bejegyzéseket.
• A napló- és statisztikatáblák, mert a cseréjük csak időt visz el.
• A szándékos hivatkozás a régi domainre, például ha a régi oldal archívumként tovább működik.

Milyen sorrendben érdemes dolgozni a migráció napján?

A belső linkeket a költöztetés után, de még a robotok beengedése előtt a leghatékonyabb lecserélni, így a feltérképezők már a végleges szerkezetet látják.

1. Mentés a régi és az új környezetről is.
2. Költöztetés, a siteurl és a home beállítása.
3. Adatbázis-csere változatonként, mindig próbafuttatással kezdve.
4. A fájlok átnézése, például így: grep -rn 'regi-domain.hu' wp-content/themes. Ide tartozik a gyermektéma, az egyedi CSS és a wp-config.php WP_HOME és WP_SITEURL konstansa is.
5. Az átirányítások élesítése a régi címekről.
6. A gyorsítótárak ürítése, feltérképezés, javítás.
7. Domainváltásnál a Search Console címváltozás-eszközének használata és az új oldaltérkép beküldése.

Hogyan derül ki feltérképezéssel, hogy maradt-e átirányításra mutató belső link?

Futtass teljes feltérképezést az új domainen, szűrj a 3xx válaszkódú belső URL-ekre, és exportáld a rájuk mutató belső linkeket a forrásoldallal együtt. Ha a lista üres, a belső linkszerkezet tiszta.

1. Indítsd el a feltérképezőt (például a Screaming Frog SEO Spidert vagy egy hasonló eszközt) az új kezdőlapról. Ha az oldalépítő JavaScripttel tölti be a menüt, kapcsold be a renderelést.
2. Szűrj a belső, átirányítással válaszoló URL-ekre. A Screaming Frogban ezt a Response Codes fül Internal Redirection (3xx) szűrője mutatja.
3. Exportáld a bejövő linkeket (Bulk Export menü, Response Codes, Internal Redirection (3xx) Inlinks). Így látod, melyik oldalon, milyen horgonyszöveggel és hol áll a régi link (menüben, láblécben vagy a tartalomban).
4. Nézd át a canonical, a hreflang, az XML-oldaltérkép, az Open Graph és a strukturált adatok URL-jeit is. Ezekre nem lehet kattintani, de a robotok követik őket.
5. Futtass listás feltérképezést a régi URL-ekre is, és ellenőrizd, hogy mindegyik egyetlen ugrással, 200-as válaszkódú oldalra visz.
6. Javítás és gyorsítótár-ürítés után ismételd meg a feltérképezést.

Hivatalosan igazolt: a Google Search Console oldalindexelési jelentése külön kategóriában mutatja az átirányítással rendelkező oldalakat, az URL-ellenőrző eszköz pedig azt, hogy a Google melyik címet tekinti kanonikusnak. Saját tapasztalat: a feltérképezés gyorsabb visszajelzést ad, mint a Search Console, mert nem kell megvárni, hogy a Google újra bejárja az oldalt. Szakmai feltételezés: a tiszta belső linkek segíthetnek lerövidíteni a migráció utáni átmeneti ingadozást, de sem helyezést, sem forgalmat nem garantálnak, mert az eredményt sok más tényező is befolyásolja.

Források és további olvasnivalók

• Google Search Central, Webhely áthelyezése URL-módosítással
• Google Search Central, Átirányítások és a Google Keresés
• Google Search Console súgó, Oldalindexelési jelentés és Címváltozás eszköz
• WP-CLI Commands dokumentáció, wp search-replace és wp db
• WordPress.org Documentation, Changing The Site URL
• PHP Manual, serialize és unserialize
• Better Search Replace bővítmény leírása (WordPress.org bővítménytár)
• Screaming Frog SEO Spider felhasználói útmutató