Shortcode-maradványok a tartalomban bővítmény eltávolítása után

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

Ha egy WordPress-oldalról lekerül egy oldalépítő vagy egy tartalmi bővítmény, a cikkekben gyakran ott marad a nyoma. A szöveg közepén olyan sorok jelennek meg, mint a [vc_row][vc_column width="1/2"] vagy az [et_pb_section fb_built="1"]. A látogató ezt hibának látja, a Google pedig a találati kivonatba is beemelheti. Az érintett oldalakat két módszerrel lehet feltérképezni, a javításra pedig három út van, eltérő kockázattal.

Mi az a shortcode-maradvány, és miért marad a szövegben?

A shortcode-maradvány olyan szögletes zárójeles kód a bejegyzés tartalmában, amelyet már egyetlen aktív bővítmény vagy téma sem értelmez, ezért a WordPress nyers szövegként jeleníti meg.

A WordPress a tartalmat megjelenítéskor futtatja át a shortcode-feldolgozón. Ez csak azokat a címkéket cseréli le, amelyeket valamelyik bővítmény vagy a téma regisztrált az add_shortcode() függvénnyel. Amíg az oldalépítő aktív, a [vc_column] egy rácsoszlop lesz a képernyőn. Ha a bővítményt kikapcsolod vagy törlöd, a regisztráció megszűnik, a kód viszont benne marad az adatbázisban, a post_content mezőben. A feldolgozó ilyenkor nem nyúl hozzá, így a böngészőbe szó szerint kerül ki.

Hivatalosan igazolt. A WordPress Shortcode API dokumentációja szerint a nem regisztrált shortcode-ok változatlanul, szövegként maradnak a kimenetben. Ez a nyitó és a záró címkére is igaz, ezért a [vc_row] és a [/vc_row] is külön megjelenik, a kettő között pedig ott van a cikk eredeti szövege.

Saját tapasztalat. A leggyakoribb forrás a WPBakery (vc_ előtag), a Divi (et_pb_), a régebbi Avada-verziók (fusion_), valamint a kisebb galéria-, gomb-, táblázat- és űrlapbővítmények. Az Elementor és a Gutenberg-blokkok másképp tárolják a felépítést, náluk ez a jelenség ritkább, a régi cikkekbe kézzel beszúrt shortcode-ok viszont ott is előfordulnak.

Miért kerülnek be a kódok a Google-kivonatba és az AI-összefoglalókba?

A Google és az AI-alapú válaszmotorok a megjelenített oldal szövegét olvassák, és a nyers shortcode ott ugyanolyan szövegnek látszik, mint a cikk többi része.

Hivatalosan igazolt. A Google Search Central leírása szerint a találati kivonat elsősorban az oldal tartalmából készül, a meta description csak akkor kerül oda, ha a Google azt jobbnak ítéli az adott kereséshez. Ha a cikk első bekezdése előtt három sor [et_pb_row] áll, a kivonat jó eséllyel ezzel indul.

Saját tapasztalat. A kár ott a legnagyobb, ahol a WordPress vagy a téma automatikusan készíti a kivonatot. Az archív oldalak, a kategórialisták, a kapcsolódó bejegyzések blokkja és sok téma Open Graph-leírása is a tartalom első mondataiból dolgozik, így a hiba a közösségi megosztás előnézetében is felbukkan. Egy blogon, ahol a kategóriaoldal tíz cikket listáz, egyetlen törölt bővítmény tíz csonka, kóddal kezdődő ajánlót hagyhat maga után.

Szakmai feltételezés. Az AI-összefoglalók (például a Google AI-áttekintés vagy a böngészni tudó csevegőmodellek) a letöltött szövegből emelnek ki részleteket. Ha a lényegi mondat két kódblokk közé szorul, a modell kevésbé tisztának láthatja az oldalt, és nagyobb eséllyel választ helyette másik forrást. Ezt közvetlenül mérni nem lehet, de a zajos szöveg aligha segíti, hogy az oldaladat idézzék.

Hogyan találod meg az összes érintett oldalt?

A legmegbízhatóbb képet két forrás összevetése adja. Az adatbázis megmutatja, hol van kód a tárolt tartalomban, a feltérképezés pedig azt, hol jelenik meg ténylegesen a nyilvános oldalon.

A kettő eltérhet. Lehet, hogy egy piszkozatban vagy a kukában lévő bejegyzésben van kód, ami senkit nem zavar. Az is előfordul, hogy a bejegyzés szövege tiszta, és a kód egy widgetből vagy a téma sablonjából jön.

Adatbázis-lekérdezés

Mielőtt bármit futtatsz, készíts teljes adatbázis-mentést. Az olvasó lekérdezéshez ez még nem lenne szükséges, de a következő lépésekben már írni fogsz, és jobb, ha a mentés a felmérés állapotát rögzíti.

phpMyAdminban vagy WP-CLI-vel (wp db query) futtasd az alábbi lekérdezést, az előtagot a saját bővítményedre cserélve. A táblanév előtagja (wp_) a te telepítéseden eltérhet.

SELECT ID, post_type, post_status, post_title FROM wp_posts WHERE post_content REGEXP '[[]/?vc_' AND post_status IN ('publish','private','future') ORDER BY post_type;

A [[] egy karakterosztály, amely a nyitó szögletes zárójelet keresi, így nem kell vele bajlódnod, hogyan kezeli az adott MySQL- vagy MariaDB-verzió a visszaperjeles kiemelést. Ha nem tudod, milyen előtagot hagyott maga után a törölt bővítmény, nyiss meg egy érintett cikket szövegnézetben, vagy futtasd a lekérdezést egymás után a vc_, et_pb_ és fusion_ mintákkal. Az eredményt mentsd táblázatba, ez lesz a munkalistád.

Feltérképezés egyedi kereséssel

A feltérképező program úgy nézi az oldalt, ahogy a látogató és a Google. A Screaming Frog SEO Spider egyedi keresés (Custom Search) funkciójában felvehetsz egy szabályt, amely a letöltött HTML-ben keresi a [vc_ vagy az [et_pb_ szöveget. Más feltérképezők, például a Sitebulb, hasonló egyedi keresést tudnak.

Saját tapasztalat. Érdemes a keresést a fő tartalmi területre szűkíteni (például az article elemre), mert a menüben vagy a láblécben lévő szögletes zárójeles szöveg, mondjuk egy „[Bővebben]” felirat, téves találatot ad. Állítsd be azt is, hogy a kategória- és címkeoldalakat is bejárja, mert az automatikus kivonatok ott jelennek meg.

Kiegészítésként a Google-ben is kereshetsz a site: operátorral és a kód szövegével. Szakmai feltételezés. A Google a szögletes zárójelet és az írásjelek nagy részét figyelmen kívül hagyja, ezért ez csak durva jelzés, teljes listát nem ad. Arra viszont jó, hogy lásd, melyik oldal kivonatában van már bent a kód, és melyiket érdemes elsőként rendbe tenni.

Hol bújik meg a kód, amit az első kör kihagy?

• A post_excerpt mező, ahol a kézzel írt kivonatok és a WooCommerce-termékek rövid leírása van.
• A wp_postmeta tábla, ahol a SEO-bővítmények saját leírást, egyes témák pedig egyedi mezőket tárolnak.
• A wp_options tábla, amelyben a szöveges widgetek tartalma van.
• Az újrahasznosítható blokkok, amelyek wp_block bejegyzéstípusként külön sorokban állnak.
• A gyerektéma sablonfájljai, ha valaki közvetlenül a sablonba írt do_shortcode() hívást.

Milyen lehetőségeid vannak a maradványok eltüntetésére?

Három út van. Átmenetileg regisztrálhatod a hiányzó shortcode-okat, hogy a WordPress megjelenítéskor eltüntesse őket, tömegesen kitisztíthatod az adatbázist, vagy oldalanként kézzel átírhatod a tartalmat.

1. Üres vagy átengedő shortcode regisztrálása

Ez a leggyorsabb és legkevésbé kockázatos első lépés, mert az adatbázishoz nem nyúl. Egy kis saját bővítménybe vagy a gyerektéma functions.php fájljába felveszed a hiányzó címkéket, és megmondod, mit adjanak vissza.

A nyitó és záró párt használó shortcode-oknál a belső tartalmat vissza kell adni, különben a cikk szövege is eltűnik.

foreach ( array( 'vc_row', 'vc_column', 'vc_column_text', 'vc_row_inner', 'vc_column_inner' ) as $tag ) { add_shortcode( $tag, function ( $atts, $content = '' ) { return do_shortcode( $content ); } ); }

Az önálló, tartalom nélküli címkéknél, például egy elválasztónál vagy egy üres térköznél, elég üres szöveget visszaadni.

add_shortcode( 'vc_empty_space', '__return_empty_string' );

Hivatalosan igazolt. Az add_shortcode(), a do_shortcode() és a __return_empty_string a WordPress magjának része, és a beépített automatikus kivonat a regisztrált shortcode-okat kiveszi a szövegből. Saját tapasztalat. Egyes témák és SEO-bővítmények saját módszerrel vágják a leírást, és ott a kód néha megmarad. A tördelés is elveszik, mert az oszlopok és sorok helyén nincs többé HTML-szerkezet, a két oszlopba rendezett szöveg egymás alá kerül.

Ezt az utat átmeneti mankónak érdemes tekinteni. Az adatbázisban a kód ott marad, és ha a kis bővítményt valaki később kikapcsolja, a hiba visszajön.

2. Tömeges tisztítás

A tömeges tisztítás a tárolt tartalomból törli a kódokat. WP-CLI-vel ez egy reguláris kifejezéses keresés-csere, amelyet először mindig próbafuttatásban indítasz.

wp search-replace '\[/?vc_[^\]]*\]' '' wp_posts --include-columns=post_content --regex --dry-run

A próbafuttatás megmutatja, hány sort érintene a csere. Ha a szám egyezik a felmérésed eredményével, futtasd le a --dry-run kapcsoló nélkül, előtte friss mentéssel. Ha van tesztkörnyezeted, ott fuss le először, és nézd át a legforgalmasabb oldalakat, mielőtt az éles adatbázisra kerül a sor.

Saját tapasztalat. A tömeges csere leggyakrabban két ponton csúszik el. Az egyik, ha egy attribútum értéke maga is tartalmaz szögletes zárójelet vagy kódolt HTML-t, mert ilyenkor a minta rossz helyen áll meg. A másik a tartalmat hordozó shortcode, például a [vc_raw_html], ahol a belső rész kódolt formában van, és a címkék törlése után olvashatatlan karaktersor marad a helyén. Ezeket a csere előtt külön listázd és kézzel kezeld.

A csere után a bekezdések is összefolyhatnak, mert az oldalépítő sokszor sortörés nélkül tette egymás mellé a blokkokat. A WordPress automatikus bekezdésezése (wpautop) a dupla sortörésből csinál bekezdést, ezért ha a záró oszlop-címkéket üres sorra cseréled, olvashatóbb eredményt kapsz.

3. Kézi átírás

A kézi átírás oldalanként halad. Megnyitod a bejegyzést, kiveszed a kódokat, és ahol a tördelés számított (két oszlop, kiemelt doboz, gomb), ott a blokkszerkesztővel újraépíted. Ez a leglassabb út, de ez adja a legjobb végeredményt, mert közben a tartalmat is átnézed.

Saját tapasztalat. A forgalmat hozó, sokat idézett oldalaknál megéri. Ilyenkor a cikk elejére egy tömör, önmagában is érthető bekezdés is bekerülhet, ami a kivonatnak és az AI-összefoglalóknak egyaránt jobb alapanyag.

Mikor melyik megoldás a biztonságos?

Ha kevés az oldal és mindegyik fontos, kézzel írd át. Ha sok az oldal és egyforma a kód, tisztíts tömegesen próbafuttatás után. Ha a látható hibát azonnal el kell tüntetni, de a tisztításra még nincs mentés vagy jóváhagyás, regisztrálj átengedő shortcode-okat.

• Az átengedő shortcode regisztrálása akkor jó, ha visszafordítható, gyors javítás kell, például közvetlenül a bővítmény eltávolítása után, vagy amíg nincs friss mentés és tesztkörnyezet.
• A tömeges tisztítás akkor jó, ha a kód egy-két ismert előtaggal, egyforma mintában fordul elő, van teljes mentés, és a próbafuttatás számai egyeznek a felméréssel.
• A kézi átírás akkor kell, ha a shortcode tartalmat hordoz (HTML-blokk, táblázat, harmonika-modul, galéria), ha a tördelés a megértéshez szükséges, vagy ha az oldal a fő forgalomhozók között van.

A gyakorlatban a három út egymás után is jól működik. Először regisztrálod a hiányzó címkéket, hogy a látható hiba eltűnjön. Utána tesztkörnyezetben lefuttatod a tömeges tisztítást az egyszerű esetekre, végül a maradék, összetett oldalakat kézzel átírod. Amikor az adatbázis-lekérdezés már nem ad találatot, a segédbővítmény kikapcsolható.

Szakmai feltételezés. Keresőoptimalizálási szempontból egyik út sem kockázatos önmagában, a valódi veszély a véletlen tartalomvesztés. Ha egy tisztítás bekezdéseket töröl, az oldal tematikus lefedettsége csökken, és ez már a láthatóságra is hathat.

Mit ellenőrizz a tisztítás után?

Akkor vagy kész, ha sem az adatbázis, sem a feltérképező nem talál kódot, és a kézzel megnyitott cikkek teljesek és olvashatók.

1. Az adatbázis-lekérdezés újrafuttatva nem ad találatot a kezelt előtagokra.
2. A feltérképező egyedi keresése sem talál kódot a nyilvános oldalakon, a kategória- és archív oldalakat is beleértve.
3. Szúrópróbaszerűen megnyitsz öt-tíz cikket, a szöveg teljes, a bekezdések elválnak, a képek és a beágyazások a helyükön vannak.
4. A közösségi megosztás előnézete (Open Graph-leírás) tiszta szöveggel indul.
5. A gyorsítótárat a bővítményben, a szerveren és a CDN-ben is ürítetted, különben a régi változat marad kint.
6. A legfontosabb oldalakra a Search Console URL-ellenőrző eszközében újrafeltérképezést kértél.
7. Az XML-oldaltérképben frissült a módosítás dátuma, ami segítheti, hogy a Google hamarabb visszatérjen.

Mennyi idő alatt tűnik el a kód a Google-kivonatból?

Ezt nem lehet előre megmondani. A kivonat akkor változik, amikor a Google újra feltérképezi és feldolgozza az oldalt, és ennek ütemét a Google dönti el.

Hivatalosan igazolt. A Google Search Central szerint az URL-ellenőrzésben kért újrafeltérképezés és az oldaltérkép beküldése jelzés a Google felé, a feldolgozás idejét viszont nem rögzíti. Saját tapasztalat. A gyakran bejárt oldalak kivonata általában hamarabb frissül, mint a régi, ritkán látogatott archív bejegyzéseké. Szakmai feltételezés. Az AI-alapú válaszmotorok saját ütemben frissítik a forrásaikat, egyes modellek régebbi letöltésből is dolgozhatnak, ezért ott egy ideig még felbukkanhat a régi szöveg.

Hogyan előzheted meg, hogy legközelebb is így járj?

Oldalépítő vagy tartalmi bővítmény eltávolítása előtt futtasd le ugyanazt az adatbázis-lekérdezést, és csak akkor töröld a bővítményt, ha tudod, hány oldalt érint és melyik úton tisztítod.

Tesztkörnyezetben kapcsold ki először, és nézd meg a legforgalmasabb oldalakat. Egyes oldalépítők gyártója leírást vagy átalakító eszközt ad a kivezetéshez. Hogy a te verziódhoz van-e ilyen, azt a gyártó dokumentációjában nézd meg, itt csak szakmai feltételezés, hogy elérhető. Új tartalomnál a blokkszerkesztő natív blokkjai kisebb függőséget jelentenek, mint egy bővítményhez kötött shortcode, így egy későbbi váltásnál kevesebb maradvánnyal kell számolnod.

Források és további olvasnivalók

• WordPress Developer Resources, Shortcode API
• WordPress Developer Resources, add_shortcode(), do_shortcode() és strip_shortcodes() függvényleírás
• WP-CLI dokumentáció, wp search-replace és wp db query parancs
• Google Search Central, Control your snippets in search results
• Google Search Central, Ask Google to recrawl your URLs
• Google Search Central, AI features and your website
• MySQL Reference Manual, Regular Expressions