Kapcsolódó cikkek blokk, kézi vagy automatikus válogatás?

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

A cikk alján álló kapcsolódó blokkot a legtöbb oldalon egyszer beállítják, aztán senki nem nézi meg újra. A bővítmény teszi a dolgát, a lista mindig tele van, és első ránézésre minden rendben. Közben ez a néhány link minden cikkről kimegy, tehát az oldal belső szerkezetének feltűnően nagy részét olyan szabály határozza meg, amelyet senki nem hagyott jóvá. Az én álláspontom az, hogy a kapcsolódó-blokk is szerkesztői döntés, ezért nem lehet teljesen gépre bízni. Azt viszont nem állítom, hogy mindent kézzel kell csinálnod, mert az nagyobb oldalon fenntarthatatlan.

Mikor elég a bővítmény automatikus kapcsolódó cikkek listája?

Az automatikus lista akkor elég, ha kevés a cikked, egy témáról írsz, és a kategóriáid tiszták. Ilyenkor a bővítmény szinte bármit választ, az olvasó témán belül marad, és a kézi válogatás ideje többe kerül annál, amit nyerhetsz vele.

Jó eséllyel beéred az automatikával ezekben a helyzetekben.

• Néhány tucat cikked van, és mindegyik ugyanahhoz a szakterülethez tartozik.
• Minden bejegyzés egyetlen, jól elnevezett kategóriában áll, a címkéket pedig következetesen használod.
• Ritkán törölsz vagy irányítasz át cikket, így kevés a halott vagy elavult cél.
• A blog inkább hír vagy magazin jellegű, ahol az olvasó böngészni jön, és nem egy tanulási útvonalat követ.

A feltételek közül a kategóriák tisztasága a legfontosabb. A bővítmény abból dolgozik, amit adsz neki. Ha a kategóriák kuszák, az ajánlások is azok lesznek, bármilyen okos a pontozása.

Mikor rontja a témacsoport szerkezetét az automatikus ajánló?

Az automatikus ajánló akkor árt, amikor szóegyezés alapján átvisz egy másik témacsoportba, vagy rendszeresen olyan cikket ajánl, amelyet már nem vállalsz. Témacsoportnál a belső linkek rajzolják ki, mi tartozik össze, ezért egy rossz ajánlás ott többet számít, mint egy magazinban.

Az elterjedt bővítmények többsége a cím, a tartalom, a kategória és a címke egyezéséből számol pontot. Ez hasznos közelítés, de a szavak hasonlósága mást mér, mint a szerkesztői összetartozás. Tipikus példa, amikor egy GA4-eseményekről szóló mérési cikk alá egy Google Ads kampányszerkezetről szóló írás kerül, mert mindkettőben sokszor szerepel a „konverzió” szó. Az olvasó ekkor kilép abból a gondolatmenetből, amelyért jött, és a pilléroldal felé vezető út megszakad.

Ezeket a hibákat látom a leggyakrabban.

• Csoportváltás. A lista szóegyezés miatt más témacsoport cikkeit hozza, miközben a saját csoport friss írásai kimaradnak.
• Elavult cél. Régi, felülírt tartalom kerül előre, mert sok benne az egyező kifejezés. Egy kivezetett funkcióról szóló leírás például évekig kaphat linket a friss cikkekből.
• Átirányított vagy törölt cél. Gyorsítótárazott listában a már átirányított cím is bent maradhat, így az olvasó és a robot felesleges kitérővel jut célba.
• Egyenetlen eloszlás. Néhány jól pontozó cikk sok helyen megjelenik, a friss írások pedig alig kapnak linket.
• Hiányzó konverziós út. A lista csak blogbejegyzésekből válogat, ezért a szolgáltatás- vagy ajánlatkérő oldal soha nem kerül az olvasó elé.

Számít-e a kapcsolódó blokk a keresőknek és az AI-rendszereknek?

A blokk linkjei közönséges belső linkek, ezért a Google ugyanúgy felfedezésre és a kontextus megértésére használhatja őket, mint a szövegben állókat, feltéve, hogy feltérképezhetők. Külön „kapcsolódó cikk” rangsorolási jelről nincs hivatalos információ, és nem is érdemes ilyet feltételezni.

A Google linkekről szóló dokumentációja szerint a feltérképezhető link egy href attribútummal ellátott a elem, és a hivatkozás szövege segít megérteni a céloldalt. A blokknál ebből két gyakorlati ellenőrzés következik. Nézd meg, hogy a linkek valódi a elemek-e, és azt is, hogy a cím szerepel-e a horgonyszövegben. Egy csupán képből álló kártya, leíró alt szöveg nélkül, keveset mond a célról.

A második kérdés a megjelenítés módja. Ha a bővítmény görgetés után, JavaScripttel tölti be a listát, a linkek nem feltétlenül kerülnek be az első HTML-válaszba. A Google képes JavaScriptet renderelni, de ennek vannak korlátai, és a külön AI-robotok viselkedéséről kevesebb a nyilvános információ. Óvatos szakmai feltételezésként azzal számolok, hogy ami a szerveroldali HTML-ben van, azt több rendszer éri el, ezért a blokkot szerveroldalon érdemes kirajzolni. Ez jó eséllyel segít, de AI-említést nem garantál.

Hogyan működik a vegyes megoldás?

A vegyes megoldásban az első egy-két helyet kézzel rögzíted, a maradék helyeket pedig szűrt automatikus lista tölti ki. A kézi helyek a szerkesztői szándékot hordozzák, az automatika pedig frissen tartja a blokkot akkor is, ha a cikkhez hónapokig nem nyúlsz.

Négyelemű blokknál ez a kiosztás jól használható.

1. 1. hely, kézi. A logikus következő lépés a témacsoporton belül, gyakran a pilléroldal vagy az a cikk, amelyet az olvasónak utána kellene elolvasnia.
2. 2. hely, kézi, ha van értelme. A cikkhez illő konverziós oldal, például a témához tartozó szolgáltatásoldal vagy egy letölthető ellenőrzőlista. Ha egy írásnál erőltetett lenne, hagyd az automatikára.
3. 3. és 4. hely, automatikus. Ugyanabból a kategóriából vagy címkéből jön, a legutóbb frissített cikkek közül, a kézi elemek kizárásával.

Bevezetéskor kezdd a pilléroldalakkal és a legtöbb organikus forgalmat kapó cikkekkel, mert ott látszik leghamarabb a hatás, és ott a legnagyobb a kockázat, ha rossz helyre visz a lista. Nem kell egyszerre minden cikket kézbe venni. A kézi mező üresen is érvényes állapot, ilyenkor a teljes blokkot az automatika tölti ki. A kategória szűrése miatt ez az alapállapot is csoporton belül marad.

A kézi választásnál azt kérdezd magadtól, mit keresne az olvasó a cikk elolvasása után. Egy kampánybeállításról szóló írás után jellemzően a mérés ellenőrzése jön, ezért az lehet a jó következő lépés akkor is, ha a két szöveg szókészlete alig fedi egymást. Ezt az összefüggést egy pontozó algoritmus nehezen találja meg, és pontosan ez az a munka, amely szerkesztői fejet kíván.

Hogyan szűrheted a listát kategória vagy címke alapján?

A legegyszerűbb szűrő az, hogy a lista csak az aktuális cikk kategóriájából válogathat, és a külön megjelölt, archivált tartalmat kizárod. A bővítmények beállításaiban ez általában kategória- vagy címkefeltételként érhető el, de a pontos elnevezés bővítményenként eltér, ezért nézd meg a sajátodét.

Egyedi sablonban a WordPress WP_Query osztályával kategóriára így szűrhetsz. A példa feltételezi, hogy a kézzel választott cikkek azonosítói a $kezi tömbben vannak, például egy egyedi mezőből.

$args = array( 'post_type' => 'post', 'post_status' => 'publish', 'posts_per_page' => 4 - count( $kezi ), 'category__in' => wp_get_post_categories( get_the_ID() ), 'category__not_in' => array( 57 ), 'post__not_in' => array_merge( array( get_the_ID() ), $kezi ), 'orderby' => 'modified', 'ignore_sticky_posts' => true, 'no_found_rows' => true ); $lista = new WP_Query( $args );

A paraméterek közül ezek döntik el a blokk minőségét.

• category__in a jelenlegi cikk kategóriáin belül tartja a listát. Ha egy cikk több kategóriában áll, a szűrő mindegyikből válogat, ezért a több kategóriás besorolás itt is visszaüt.
• category__not_in kizárja a megadott kategóriát. Az 57-es azonosító csak minta, ide a saját archív vagy kivezetett kategóriád azonosítója kerül.
• post__not_in kiveszi az aktuális cikket és a kézi elemeket, így nem jelenik meg semmi kétszer.
• post_status csak közzétett bejegyzést enged át, tehát a piszkozatba visszatett cikk magától kiesik.
• orderby a frissítés dátuma szerint rendez, így a karbantartott cikkek kerülnek előre.

Ha a kategória túl tág, címkével szűkíts. Ehhez a category__in helyére a 'tag__in' => wp_get_post_tags( get_the_ID(), array( 'fields' => 'ids' ) ) sor kerül. Ez akkor működik jól, ha a címkét témacsoport-jelölőként használod, és csoportonként egy, előre rögzített címke van. Spontán, cikkenként kitalált címkékkel a szűrő szétesik.

Két buktatóra figyelj a kódnál. A kézi elemek lekérdezésénél a post__in üres tömbbel nem szűr semmit, tehát az összes cikket visszaadhatja, ezért csak akkor futtasd, ha van kézi elem, és 'orderby' => 'post__in' értékkel tartsd meg a sorrendet. Az automatikus lekérdezés is csak akkor fusson, ha marad szabad hely, mert a nulla darabszám nem azt jelenti, amit várnál. Élesítés előtt a kódot tesztkörnyezetben próbáld ki.

Mit ellenőrizz, amikor átnézed a blokkot?

Három kérdés a minimum, hogy csoporton belül marad-e a blokk, élő oldalra mutat-e, és van-e benne konverziós oldal. A többi pont finomítás, de egy nagyobb oldalon ezek is sok rejtett hibát hoznak felszínre.

1. Csoporton belül marad? Az elemek legalább fele ugyanabba a témacsoportba tartozik, és a kilógó elem mellett van szerkesztői indok.
2. Élő oldalra mutat? Minden cél 200-as státusszal válaszol, közvetlen a hivatkozás, és nincs benne átirányítás vagy 404-es oldal.
3. Van benne konverziós oldal? Ahol a cikk vásárlási vagy ajánlatkérési szándékhoz közel áll, ott a blokkból elérhető a következő üzleti lépés.
4. Friss a tartalom? A célcikkben nincs kivezetett funkció, elavult képernyőleírás vagy túlhaladott ajánlás.
5. Beszédes a horgonyszöveg? A link szövege a cikk valódi címe, és a kártya akkor is érthető, ha a kép nem töltődik be.
6. Bent van a HTML-ben? Az oldal forrásában vagy a renderelt HTML-ben ott vannak a linkek, valódi a elemként.
7. Nincs ismétlés? A blokk nem ugyanazt linkeli, amire a szöveg már kétszer hivatkozott, és az elemek nem egymás közeli másolatai.
8. Egyenletes az eloszlás? Nem ugyanaz a három cikk áll mindenhol, és a friss írások is kapnak linket.

A gyakorlatban egy oldalfeltérképező eszközzel exportálhatod a belső linkeket, majd szűrhetsz a blokk HTML-szakaszára. A státuszkódok és a linkek eloszlása így egy táblázatban átnézhető, és a csoporthoz tartozást már a kategória oszlop alapján is gyorsan megítéled.

Milyen gyakran érdemes átnézni a kapcsolódó blokkokat?

Negyedévente elég a kiemelt cikkek ellenőrzése, a teljes körös átnézés pedig minden nagyobb szerkezeti változásnál indokolt. Ilyen esemény a cikkek összevonása, a kategóriák átalakítása, a domainváltás vagy a bővítmény cseréje.

Tedd a szerkesztői folyamat részévé az ellenőrzést. Új cikk közzétételekor válaszd ki az első kézi ajánlást, és gondold végig, melyik két régebbi írásba érdemes bekötni az újat. Cikk törlésekor vagy átirányításakor keresd meg, hol áll kézi ajánlásként, és cseréld ki. Az automatikus részt a gyorsítótár ürítése frissíti, a kézi hivatkozásokért viszont te felelsz, ezért ezekről érdemes egyszerű listát vezetni.

A bővítmény teljesítményét is nézd meg. Egyes megoldások minden oldalbetöltésnél nehéz adatbázis-lekérdezést futtathatnak, ezért nagy cikkszámnál a gyorsítótárazás vagy az előre kiszámolt kapcsolatok sokat számíthatnak.

Mi igazolt, mi tapasztalat, és mi feltételezés ebben a témában?

Hivatalosan igazolt

• A Google a href attribútummal ellátott a elemeket tudja megbízhatóan linkként feltérképezni, és a hivatkozás szövegét a céloldal megértéséhez is felhasználja.
• A belső linkek segítenek a keresőknek új oldalakat találni.
• A WP_Query paraméterei a WordPress fejlesztői dokumentációjában szerepelnek, így a fenti szűrők viselkedése ott visszaellenőrizhető.

Saját tapasztalat

• Az automatikus listák a szóegyezés miatt gyakran csoporton kívülre visznek, főleg azokon az oldalakon, ahol több témakör ugyanazt a szakszókincset használja.
• A legtöbb hibát a régi cikkek és a kusza kategóriák okozzák, a bővítmény kiválasztása ehhez képest kisebb tényező.
• A kézi első hely a felelős szerkesztésre is rászoktat, mert ki kell mondani, mi a cikk utáni következő lépés.

Szakmai feltételezés

• A következetesen csoporton belül maradó blokk segítheti, hogy a keresők és a nyelvi modellek a cikkeket összetartozó tudásként értelmezzék. Erre nincs hivatalos megerősítés.
• A szerveroldali HTML-ben álló linkeket több robot éri el, mint a később betöltött listát. Ez robotonként eltérhet.
• A vegyes megoldás hatását nehéz elkülönítve mérni, mert a helyezést sok más tényező is mozgatja, ezért helyezésjavulást vagy AI-említést senki nem ígérhet belőle.

Források és további olvasnivalók

• Google Search Central, a linkekkel kapcsolatos ajánlott gyakorlatok
• Google Search Central, SEO kezdő útmutató
• Google Search Central, a JavaScript-alapú keresőoptimalizálás alapjai
• WordPress Developer Resources, WP_Query osztály
• WordPress Developer Resources, get_post_meta és wp_get_post_categories függvények
• W3C, HTML Living Standard hivatkozás és WCAG útmutató a linkek céljáról