Minden B2B marketinges, aki elkezd felmérni egy weboldal-personalizációs projektet, előbb-utóbb ugyanazt a kérdést kapja valakitől a SEO-csapatból: „Ez nem fogja tönkretenni az organikus helyezéseinket?” Az aggodalom általában a cloaking körül forog, és szinte mindig leállítja a personalizációs projekteket, mielőtt elindulnának. A félelem az, hogy a Googlebot az oldal egyik változatát látja, egy emberi látogató egy másikat, és a Google megbünteti az oldalt az eltérő tartalomért.
Röviden: nem, ha helyesen építed fel. A Google spamszabályzata a helyezések manipulálására megváltoztatott tartalmat célozza, nem a látogatókhoz igazított tartalmat. A valódi kockázatok technikaiak: rossz változat indexelése, duplikált URL-ek, lassú vagy blokkolt renderelés és gyorsítótárazási hibák. Ezek saját magad okozta rangsorolási problémákat idéznek elő, amelyeknek semmi közük a büntetésekhez, és ezekre kell felkészülni.
Ez a cikk bemutatja, mit mond a Google dokumentációja, melyek azok a konkrét esetek, amikor a személyre szabás és a SEO ütközik, milyen technikai beállítás tartja működőképesen mindkettőt, és mi a leggyakoribb tervezési hiba.
Gyors válasz: hogyan hat a személyre szabás a SEO-ra
A személyre szabás csak a Google által feltérképezett oldalon és annak betöltési sebességén keresztül hat a SEO-ra. Ha a robotok és az első látogatók egyetlen URL-en teljes alapértelmezett oldalt kapnak, és a változatok az oldal lassítása nélkül cserélik rajta a tartalmat, a rangsorolás nem változik. SEO-kárt egy változat indexelése, a változatok több URL-re bontása, a renderelés blokkolása, vagy egyetlen látogató változatának mindenki számára való gyorsítótárazása okoz.
A „személyre szabás és SEO” mögött ráadásul két különböző kérdés rejtőzik, és érdemes szétválasztani őket:
- A Google a saját találatait perszonalizálja. A Google hely, nyelv és korlátozott mértékben keresési előzmények alapján igazítja a találatokat. Ezért láthat két ember kissé eltérő rangsort ugyanarra a lekérdezésre. Ezt nem tudod befolyásolni, és a legtöbb B2B kulcsszónál csak kicsit mozdítja el a pozíciókat. A rangsorokat semleges helyről kövesd, és a saját böngésződben végzett szúrópróbák helyett a Search Console átlagait használd.
- Te szabod személyre a weboldaladat. A cikk további része erről szól: hogyan mutass különböző tartalmat különböző látogatóknak a saját oldalaidon, és hogyan tedd ezt úgy, hogy ne rontsd az oldalak rangsorolását.
Személyre szabási típusok és SEO-kockázatuk
Nem minden személyre szabás jár ugyanakkora kockázattal. Így értékeljük a gyakori B2B mintákat:
| Személyre szabás típusa | SEO-kockázat | Miért | Biztonságos beállítás |
|---|---|---|---|
| Logók, esettanulmányok vagy ajánlások cseréje iparág szerint | Alacsony | Az oldal fő témája és szövege ugyanaz marad | Alapértelmezett a HTML-ben, csere betöltés után vagy az edge-en |
| Főcím- és CTA-variánsok szegmensenként | Alacsony–közepes | A H1 rangsorolási jel, így az alapértelmezett H1-nek tartalmaznia kell a kulcsszót | A kulcsszó maradjon az alapértelmezett H1-ben; a variánsok szegmensre szabott megfogalmazást adnak hozzá |
| Földrajzi vagy nyelvi átirányítások | Közepes | A Googlebot főleg az USA-ból térképez fel, és lehet, hogy soha nem látja a többi változatot | Külön URL-ek hreflanggal; javasolj, ne kényszeríts átirányítást |
| Saját lekérdezési paraméteres URL-en futó változatok | Közepes | A duplikált oldalak versengenek egymással, és megosztják a linkeket | Minden variánsnál kanonikus URL az alapértelmezett URL-re |
| Teljes szakaszok elrejtése vagy cseréje egyes látogatóknál | Magas | A feltérképezett tartalom nagyon eltérhet attól, amit a felhasználók látnak | Adj hozzá szekciókat a szegmensekhez, ne távolítsd el az alapértelmezett tartalmat |
| Más tartalom a Googlebotnak, mint minden emberi látogatónak | Magas (cloaking) | Megfelel a cloaking Google-féle definíciójának | A botok ugyanazt az alapértelmezett oldalt kapják, mint egy ismeretlen látogató |
Mit mond valójában a Google a személyre szabott tartalomról
A Google álláspontja a személyre szabásról megengedőbb, mint ahogy a legtöbb SEO-csapat gondolja. Spam-irányelveiben a Google a cloakingot így határozza meg: „presenting different content to users and search engines with the intent to manipulate search rankings and mislead users.” A kulcskifejezés a „to manipulate”. A látogatói jellemzőkön alapuló személyre szabás – például iparágspecifikus esettanulmány megjelenítése egy egészségügyi cégtől érkező látogatónak – nem cloaking, mert nem arra szolgál, hogy megtévessze a Googlebotot vagy kijátssza a rangsorolást. Arra szolgál, hogy jobban kiszolgálja a látogatót. Ha egy külső linképítő cég auditálja az oldaladat, győződj meg róla, hogy érti ezt a különbséget, mielőtt megjelölné a személyre szabott oldalakat.
A Google dinamikus megjelenítésről szóló oldala hasonlót mond: „As long as your dynamic rendering produces similar content, Googlebot won't view dynamic rendering as cloaking.” Ugyanez az oldal a dinamikus megjelenítést olyan kerülőmegoldásnak nevezi, amelyet már nem ajánl, ezért ne értelmezd úgy, mintha támogatná, hogy a robotok külön változatot kapjanak. A biztonságos értelmezés: amit a Googlebot kap, annak meg kell egyeznie azzal, amit egy ismeretlen emberi látogató kap.
A nyelvi és országos változatoknál a Google többrégiós webhelyek kezeléséről szóló útmutatója nem javasolja a felhasználók nyelv szerinti automatikus átirányítását, és megjegyzi, hogy a Google feltérképezéseinek többsége az USA-ból indul, így a csak helyi változatban elérhető tartalmat lehet, hogy soha nem térképezik fel. Ehelyett használj külön URL-eket hreflanggel.
A gyakorlatban a rangsorolási károkat technikai hibák okozzák: rossz változat indexelése, a kanonikus jelzések elrontása vagy a Googlebot kizárása a kritikus tartalomból.
Ahol a perszonalizáció és a SEO valóban ütközik
A súrlódási pontok szűkebbek, mint ahogy a legtöbb csapat gondolja. Öt minta lefedi a legtöbb SEO-problémát, amit egy personalizációs bevezetés okozhat.
1. Perszonalizált variáns indexelése kanonikus változatként
Példa: egy csapat személyre szabott kezdőlapot épít öt iparági változattal. A szerver véletlenül épp az egészségügyi változatot adja ki, amikor a Googlebot feltérképez, és hirtelen ez az iparágspecifikus verzió rangsorolódik. Bárki, aki a márkanevedre keres, egy olyan szegmensnek készült oldalra érkezik, amelyhez nem tartozik.
A megoldás nem az, hogy elrejted a változatokat a Googlebot elől, hanem hogy az alapértelmezett élmény – amelyet az ismeretlen vagy be nem sorolt látogatók látnak – legyen az is, amit a Googlebot következetesen lát. A botoknak mindig az alapértelmezett változatra kell kerülniük, soha nem egy szegmensbe.
2. Rossz URL-re mutató canonical tagek
A csapatok néha minden személyre szabott változatnak saját URL-t adnak ( /?segment=healthcare, /?segment=finance), anélkül hogy helyesen beállítanák a canonical tageket. A Google-nek ekkor kell eldöntenie, melyik változatot indexelje, és ritkán azt választja, amelyet te rangsoroltatni szeretnél. Ha a személyre szabott változatokat külön URL-eken szeretnéd tartani, minden változat canonical tagje az alapértelmezett verzióra mutasson. Ha egyetlen, látogatótól függően változó URL-t szeretnél, tartsd meg egy URL-nek, és a tartalmat szerveroldalon vagy indexelés után hidratáló kliensoldali megjelenítéssel szolgáld ki.
3. Lassú Time-to-First-Byte a szerveroldali személyre szabás miatt
Ha a válasz előtt döntöd el, milyen tartalmat jelenítesz meg, és a személyre szabási hívás a kritikus útvonalon van, az minden kéréshez késleltetést ad. A Core Web Vitals ezt észleli: a Google a Largest Contentful Paint értéket legfeljebb 2,5 másodperc esetén tekinti jónak, és egy döntési lépés, amely a kulcsoldalakat e fölé tolja, a felhasználóknak és az oldalélmény-jelzéseknek is árt. Indulás előtt mérd az első bájtig eltelt időt (TTFB) a személyre szabási hívással és anélkül. A megoldás, hogy a nem kritikus személyre szabási döntéseket az edge-re vagy a kliensre helyezed, és meggyőződsz róla, hogy a szolgáltatód valódi edge-futtatást támogat, nem regionális hubokon keresztüli irányítást.
4. Renderelést blokkoló kliensoldali perszonalizáció
Azok a kliensoldali személyre szabási szkriptek, amelyek a szegmensek lekérése közben blokkolják a fő szálat, elrendezés-elcsúszást és késleltetett interaktivitást okoznak. A Googlebot tud JavaScriptet renderelni, de a gyors, nem blokkoló szkripteket részesíti előnyben. Ha a személyre szabási könyvtárad egy szegmensdöntésre vár, mielőtt megjelenítené a hero szekciót, a Googlebot üres herót indexelhet, vagy teljesen kihagyhatja a tartalmat. Használj nem blokkoló szegmensdöntéseket egy azonnal megjelenő alapállapottal, amely a szegmens meghatározása után cseréli a tartalmat. Arról, hogyan foglalj helyet, hogy egy lecserélt blokk ne tologassa az oldalt, ebben az útmutatóban olvashatsz: a cumulative layout shift megelőzése.
5. A CDN-gyorsítótárazás ütközik a személyre szabott válaszokkal
Ha a CDN-ed gyorsítótárazza a személyre szabott választ, és a következő látogatóknak is azt szolgálja ki, két dolog romlik el egyszerre: a személyre szabás rossz lesz azoknak a látogatóknak, és a gyorsítótárazott variáns lesz az, amit a Googlebot az újrafeltérképezéskor lát. Minden CDN előtt történő személyre szabáshoz vary fejléc kell a szegmensjelzésre, vagy az edge-en kell történnie, ahol minden látogató saját döntést kap a gyorsítótár szennyezése nélkül.
A technikai beállítás, amely mindkettőt működésben tartja
A SEO-t tiszteletben tartó perszonalizációs beállításnak van néhány kötelező eleme. Ha ezeket már az elején jól csinálod, megelőzöd a fenti problémákat.
- Stabil alapértelmezett élmény. Az ismeretlen látogatóknak és botoknak kiszolgált oldalnak teljesnek, koherensnek kell lennie, és azt kell tükröznie, amire rangsorolni szeretnél. Ez a SEO szempontjából kanonikus tartalmad. A személyre szabott változatok erre épülő cserék, nem helyettesítik.
- Logikai oldalanként egy URL. A főoldal egy URL, nem öt. Az iparági oldalak egyenként egy-egy URL. A változatok ugyanazon az URL-en jelennek meg, nem egyedi query stringgel kiegészített verziókon. Így tiszták maradnak a kanonikus jelzéseid, és koncentrálódik a linkérték.
- Szerveroldali vagy edge-futtatás a hajtás feletti tartalomhoz. Azt a tartalmat, amelyet a Googlebotnak látnia kell az indexeléshez, kliensoldali döntésekre várás nélkül kell renderelni. A hajtás alatti személyre szabás futhat a megjelenítés után.
- Botfelismerés, amely az alapváltozatra áll vissza. A legtöbb perszonalizációs platformon van egy kapcsoló, amely a Googlebotnak és más ismert crawlereknek az alapértelmezett élményt küldi. Kapcsold be. Ez nem cloaking, hanem következetesség: biztosítod, hogy az indexelt változat megegyezzen a keresésre optimalizált alapváltozattal.
- Schema.org jelölés az alapváltozaton. A strukturált adatoknak az alapértelmezett tartalomra kell hivatkozniuk, nem a személyre szabott variánsokra. Ha az esettanulmány-szekciód iparág szerint cserélődik, az Article sémának az alapértelmezett esettanulmányt kell leírnia, nem az éppen megjelenítettet.
- Vary fejlécek vagy edge-alapú döntéshozatal. Minden CDN-nek, amely az origin szervered és a látogató között helyezkedik el, tudnia kell, mikor kerülje meg a gyorsítótárat. A hiányzó Vary fejléc a leggyakoribb oka annak, hogy a perszonalizáció átszivárog a látogatók között.
Egyszerűen fogalmazva: a personalizáció egy keresőre optimalizált alapra épülő réteg, nem helyettesíti azt. A problémák akkor kezdődnek, amikor a személyre szabott élmény lesz az elsődleges, és az alapértelmezett csak utólagos gondolat.
Amit a legtöbb csapat elhibáz
A mi véleményünk: a személyre szabás legnagyobb SEO-kockázata nem a cloaking vagy a büntetések. Hanem az, ha rossz kiindulási alapról indulsz.
A csapatok a personalizációt egy gyenge alapértelmezett oldal javítására használják. Szándékosan általános alapoldalt építenek, abból kiindulva, hogy a legtöbb látogatónál úgyis felülírják, aztán nézik, ahogy esnek a helyezések. Az alapoldalt indexeli a Google, és az organikus forgalmad nagy része soha nem indít el personalizációs szabályt. Ha gyenge az alapértelmezett változat, gyengék a helyezések is, és az a forgalom, amelyet a personalizáció konvertálhatott volna, meg sem érkezik.
Az általunk javasolt sorrend ennek a fordítottja: először fektess be a lehető legerősebb általános oldalba a SEO kedvéért, és utána építs rá személyre szabást. A kezdőlap-személyre szabási útmutatónk és a B2B weboldal-személyre szabás működéséről szóló áttekintésünk ugyanezt mondja a konverzió oldaláról.
Max Desiak, B2B SaaS SEO- és AEO-tanácsadó, aki hosszú értékesítési ciklusú, magas ACV-jű márkákkal dolgozik, hozzáteszi, hogy hosszú értékesítési ciklusnál az alapváltozat még fontosabb: „Buying committees usually reach your default page first, through organic or AI search, before any segment signal exists. That page has to carry the keyword and the argument on its own, because personalization can only improve traffic you have already earned.”
A második gyakori hiba, hogy a SEO-t és a personalizációt külön csapatként, külön roadmappel kezelik. A gyakorlatban a SEO-csapat felel az alaptartalomért, a meta tagekért és a schemáért, a personalizációs csapat pedig a rájuk épülő változatokért. Ha nem egyeztetnek, a személyre szabott változatok csendben eltávolodhatnak attól, amit a SEO-csapat optimalizált, és az indexelt oldal és a személyre szabott oldal közti rés addig nő, amíg a riportok furcsán nem kezdenek kinézni. Egy tünet: a SEO-csapat azon csodálkozik, miért konvertál gyengén egy élen rangsoroló oldal, a personalizációs csapat pedig azon, miért nem látják soha a célaccountok a nekik készült változatokat. Ha minden fontos oldalnak van egy közös felelőse, és az alapértelmezett szöveg az elfogadott igazságforrás, ennek nagy része elkerülhető.
Gyakorlati teszt a bevezetés előtt
Mielőtt bármilyen perszonalizációt indítanál egy organikus forgalmat kapó oldalon, futtasd le ezt az ellenőrzést. Nyisd meg az oldalt inkognitóablakban, sütik nélkül. Aztán nyisd meg újra Googlebotként egy user-agent-váltóval vagy a Google Search Console URL-ellenőrző eszközével. Hasonlítsd össze a kettőt. A fő tartalomnak egyeznie kell. Ha nem egyezik, vagy a botokra vonatkozó szabályod hibás, vagy az alapértelmezett változatot szennyezi egy perszonalizációs szabály, amely akkor is elsül, amikor nem kellene. A tágabb programhoz lásd a pipeline köré tervezett B2B SEO-ról szóló útmutatónkat.
Ezután a megjelenített HTML-t ellenőrizd, ne a nyers HTML-t. A Search Console URL-ellenőrző eszközével nézd meg, mit indexelt ténylegesen a Googlebot. Ha a kritikus tartalom, például az árazás, az esettanulmányok vagy az ajánlások csak a személyre szabás lefutása után jelennek meg a megjelenített kimenetben, kliensoldali időzítési problémád van. Tedd ezt a tartalmat a szerver válaszába.
Végül ellenőrizd, hogy nem romlottak-e a Core Web Vitals mutatóid. Egy nagy forgalmú oldalon használd a PageSpeed Insights eszközt a perszonalizáció bekapcsolása előtt és után. Néhány száz ezredmásodperces romlás könnyen elsikkad, ha nem keresed. Ha a perszonalizációs platformod a kritikus útvonalon van, és késleltetést okoz, a nem sürgős döntéseket helyezd későbbre.
Hogyan illeszkedik ez a többi személyre szabási biztosítékhoz
A SEO-biztonság egyike annak a három működési kérdésnek, amely minden B2B személyre szabási bevezetésnél felmerül. A másik kettő az adatvédelmi megfelelés, amelyről az adatvédelmi megfelelési útmutatónkban írtunk, és a variánsok közötti vizuális egységesség, amelyről a személyre szabott B2B weboldalak tervezési mintáiról szóló cikkünkben. Mindhárom ugyanarra az elvre épül: a személyre szabásnak biztonságos rétegnek kell lennie egy szilárd alap tetején, nem pedig az alapszintű fegyelem helyettesítőjének.
Bármilyen eszközt használsz, bevezetés előtt ellenőrizz négy dolgot: az ismert crawlerek az alapértelmezett élményt kapják, a variánsok ugyanazon az URL-en élnek (vagy arra kanonizálnak), az alapértelmezett változat megjelenik anélkül, hogy szegmensdöntésre várna, és a személyre szabott válaszokat soha nem gyorsítótárazzák más látogatók számára. Ha a Markettailort használod, a szegmentációs szabályai és az A/B tesztelése variánsként fut a meglévő URL-jeiden, így a fenti ellenőrzések közvetlenül érvényesek; az inkognitó vs. URL-vizsgálat tesztet mindenképp futtasd le a saját oldalaidon.
A kétmondatos összefoglaló
A weboldal-személyre szabás nem árt a SEO-nak, ha erős alapváltozatból indulsz, logikai oldalanként egy URL-t tartasz meg, és a robotokat az alapértelmezett változatra engeded. Akkor árt, ha a csapatok a személyre szabást a jó általános tartalom helyettesítőjeként kezelik, kihagyják a technikai beállítást, vagy hagyják, hogy a kliensoldali szkriptek késleltessék a Googlebot hozzáférését a kritikus tartalomhoz.
Ha a SEO-aggály tartja vissza a perszonalizációs projektet, futtasd le a fenti indulás előtti tesztet egy oldalon, és oszd meg az eredményt a SEO-csapattal; így egy általános aggodalomból ellenőrizhető lista lesz. Az adatoldalról lásd, hogyan táplálja a látogatóazonosítás a szegmenseket, vagy hasonlítsd össze a csomagokat az árazási oldalon.
Gyakran ismételt kérdések
Cloakingnak számít a személyre szabás?
Nem, amíg a cél a látogatók jobb kiszolgálása, és a Googlebot ugyanazt az alapértelmezett oldalt kapja, amit egy ismeretlen látogató kapna. A cloaking azt jelenti, hogy a keresőknek a felhasználók által látottól eltérő tartalmat mutatsz a helyezések manipulálása érdekében. Egy esettanulmány iparág szerinti cseréje nem ilyen.
A Googlebot az oldal perszonalizált változatát lássa?
Nem. Hagyd, hogy a keresőrobotok mindig az alapértelmezett élményt kapják. Így az indexelt tartalom stabil marad, és az oldal arra rangsorol, amire optimalizáltad, nem arra a szegmensre, amelyet véletlenül a feltérképezés idején szolgáltak ki.
Ront a kliensoldali perszonalizáció a Core Web Vitals értékeken?
Igen, lassíthatja. Azok a szkriptek, amelyek a szegmens meghatározásáig elrejtik a tartalmat, késleltetik a Largest Contentful Paintet, és elrendezés-eltolódást okoznak. Az alapértelmezett változatot azonnal jelenítsd meg, a cserélt elemeknek tarts fenn helyet, a perszonalizációs szkriptet pedig aszinkron módon töltsd be.
Személyre szabja a Google a keresési találatokat?
Igen, főleg hely és nyelv szerint, kisebb mértékben a keresési előzmények alapján. Ez külön téma a saját weboldalad személyre szabásától. A rangsorolás megítéléséhez a Search Console átlagos pozícióját használd, ne a saját böngésződet.
Tesztelhetek A/B tesztekkel személyre szabott oldalakat a SEO károsítása nélkül?
Igen. A Google weboldal-tesztelési útmutatása szerint a változat URL-eken rel=canonicalt kell használni, a tesztváltozatokhoz 301 helyett 302-es átirányítást, és a teszteket le kell állítani, amint megvan a válasz. A konverzióoptimalizálási útmutatónk bemutatja, hogyan tervezz olyan teszteket, amelyek ésszerű idő alatt lefutnak.