Kuidas personaliseerimine SEO-d mõjutab? B2B juhend

Iga B2B turundaja, kes hakkab veebisaidi personaliseerimise projekti ulatust kavandama, saab lõpuks SEO-meeskonnalt sama küsimuse: „Kas see lööb meie orgaanilised positsioonid põhja?“ Mure on tavaliselt seotud varjamisega (cloaking) ja peaaegu alati peatab see personaliseerimisprojektid enne, kui need üldse käima saavad. Hirm on, et Googlebot näeb lehe üht versiooni, inimkülastaja teist, ja Google karistab saiti mittevastava sisu näitamise eest.

Lühike vastus on ei, kui see on õigesti üles ehitatud. Google'i rämpsposti eeskirjad on suunatud sisule, mida muudetakse positsioonide manipuleerimiseks, mitte külastajatele kohandatud sisule. Tegelikud riskid on tehnilised: vale variandi indekseerimine, dubleeritud URL-id, aeglane või blokeeritud renderdamine ja vahemälu vead. Need põhjustavad ise tekitatud positsiooniprobleeme, millel pole karistustega midagi pistmist, ja just nendeks tuleb valmistuda.

See postitus käsitleb, mida Google'i dokumentatsioon ütleb, konkreetseid olukordi, kus personaliseerimine ja SEO põrkuvad, tehnilist seadistust, mis hoiab mõlemad töös, ning kõige levinumat planeerimisviga.

Kiire vastus: kuidas personaliseerimine SEO-d mõjutab

Personaliseerimine mõjutab SEO-d ainult lehe kaudu, mida Google indekseerib, ja selle kaudu, kui kiiresti see laadib. Kui indekseerijad ja esmakülastajad saavad ühel URL-il täieliku vaikelehe ning variandid vahetavad selle peal sisu lehte aeglustamata, ei mõjuta see positsioone. SEO-kahju tuleneb variandi indekseerimisest, variantide jagamisest URL-ide vahel, renderdamise blokeerimisest või ühe külastaja versiooni vahemällu salvestamisest kõigile.

Sõnapaari „personaliseerimine ja SEO“ taga peitub ka kaks erinevat küsimust ning neid tasub eristada:

• Google personaliseerib oma tulemusi. Google kohandab tulemusi asukoha, keele ja piiratud määral otsinguajaloo järgi. Seepärast võivad kaks inimest näha sama päringu puhul veidi erinevaid positsioone. Te ei saa seda kontrollida ja enamiku B2B märksõnade puhul muudab see positsioone vaid veidi. Jälgige positsioone neutraalsest asukohast ja kasutage oma brauseris tehtud pistelise kontrolli asemel Search Console’i keskmisi.
• Teie personaliseerite oma veebilehte. Sellest räägib ülejäänud postitus: erinevatele külastajatele erineva sisu näitamine oma lehtedel ja kuidas seda teha nii, et lehtede järjestus ei kannataks.

Personaliseerimise tüübid ja nende SEO-risk

Mitte iga personaliseerimise liik ei kanna sama riski. Meie hinnang levinud B2B mustritele:

Mida Google personaliseeritud sisu kohta tegelikult ütleb

Google'i seisukoht personaliseerimise suhtes on lubavam, kui enamik SEO-meeskondi eeldab. Oma rämpsposti eeskirjades määratleb Google varjamise (cloaking) kui „kasutajatele ja otsingumootoritele erineva sisu esitamise eesmärgiga manipuleerida otsingu järjestust ja eksitada kasutajaid“. Võtmefraas on „manipuleerida“. Külastaja tunnustel põhinev personaliseerimine, näiteks tegevusalapõhise juhtumiuuringu näitamine tervishoiuettevõtte külastajale, ei ole varjamine, sest see pole mõeldud Googleboti petmiseks ega järjestusega mängimiseks. See on mõeldud külastajat paremini teenindama. Kui teie veebilehte auditeerib väline lingiehitusettevõte, veenduge, et nad mõistavad seda erinevust, enne kui nad personaliseeritud lehti märgistavad.

Google'i leht dünaamilise renderdamise kohta teeb seotud tähelepaneku: „As long as your dynamic rendering produces similar content, Googlebot won't view dynamic rendering as cloaking.“ Sama leht nimetab dünaamilist renderdamist ajutiseks lahenduseks, mida ta enam ei soovita, nii et ärge lugege seda heakskiiduna robotitele erilise versiooni pakkumiseks. Turvaline tõlgendus on: Googlebot peaks saama sama, mida saab tundmatu inimkülastaja.

Keele- ja riigivariantide puhul soovitab Google'i juhend mitmepiirkonnaliste veebilehtede haldamise kohta mitte suunata kasutajaid keele järgi automaatselt ümber ja märgib, et enamik Google'i roomamisi pärineb USA-st, nii et ainult lokaadipõhist sisu ei pruugita kunagi roomata. Kasutage selle asemel eraldi URL-e koos hreflangiga.

Praktikas kahjustavad positsioone tehnilised vead: vale variandi indekseerimine, kanooniliste signaalide rikkumine või Googleboti blokeerimine olulise sisu juurest.

Kus isikupärastamine ja SEO päriselt kokku põrkavad

Hõõrdepunkte on vähem, kui enamik meeskondi eeldab. Viis mustrit katavad suurema osa SEO-probleemidest, mida personaliseerimise kasutuselevõtt võib põhjustada.

1. Isikupärastatud variandi indekseerimine kanoonilise versioonina

Näide: meeskond loob personaliseeritud avalehe viie tööstusharu variandiga. Server juhtub Googleboti indekseerimise ajal kuvama tervishoiu varianti ja äkki on just see tööstusharupõhine versioon see, mis otsingus kuvatakse. Igaüks, kes otsib teie brändi nime, jõuab lehele, mis on loodud segmendile, kuhu ta ei kuulu.

Lahendus ei ole variantide peitmine Googlebotilt. Tuleb tagada, et vaikekogemus – see, mida näidatakse tundmatutele või kategoriseerimata külastajatele – oleks ka see, mida Googlebot järjepidevalt näeb. Robotid peaksid alati jõudma vaikeversioonini, mitte kunagi segmenti.

2. Vale URL-ile osutavad canonical-sildid

Meeskonnad annavad mõnikord igale personaliseeritud variandile oma URL-i ( /?segment=healthcare, /?segment=finance), seadistamata kanoonilisi silte õigesti. Siis peab Google valima, millist varianti indekseerida, ja valitu on harva see, mida soovite otsingus näha. Kui soovite, et personaliseerimisvariandid asuksid eraldi URL-idel, suunake iga variandi kanooniline silt vaikeversioonile. Kui soovite üht URL-i, mis muutub külastaja põhjal, hoidke see ühe URL-ina ja edastage sisu serveripoolselt või kliendipoolse renderdamise kaudu, mis hüdreerub pärast indekseerimist.

3. Aeglane Time-to-First-Byte serveripoolse personaliseerimise tõttu

Enne vastamist renderdatava sisu üle otsustamine lisab igale päringule viivitust, kui personaliseerimiskutse asub kriitilisel teel. Core Web Vitals märkab seda: Google peab Largest Contentful Painti heaks, kui see on 2,5 sekundit või vähem, ja otsustusetapp, mis lükkab võtmelehed sellest kaugemale, kahjustab nii kasutajaid kui ka lehekogemuse signaale. Mõõtke enne käivitamist esimese baidi aega (TTFB) personaliseerimiskutsega ja ilma. Lahendus on viia mittekriitilised personaliseerimisotsused servale (edge) või kliendi poolele ja veenduda, et teie tarnija toetab tõelist servas täitmist, mitte piirkondliku jaoturi kaudu suunamist.

4. Kliendipoolne isikupärastamine, mis blokeerib renderdamise

Kliendipoolsed personaliseerimisskriptid, mis blokeerivad segmentide toomise ajal põhilõime, põhjustavad paigutuse nihkumist ja hilinenud interaktiivsust. Googlebot suudab JavaScripti renderdada, kuid eelistab kiireid, mitteblokeerivaid skripte. Kui teie personaliseerimisteek ootab enne päisejaotise näitamist segmendiotsust, võib Googlebot indekseerida tühja päise või sisu täielikult vahele jätta. Kasutage mitteblokeerivaid segmendiotsuseid koos vaikeolekuga, mis renderdub kohe ja vahetab sisu, kui segment selgub. Ruumi reserveerimise mehaanika kohta, et vahetatud plokk lehte ei nihutaks, vaadake seda juhendit kumulatiivse paigutuse nihke vältimisest.

5. CDN-i vahemälu põrkumine personaliseeritud vastustega

Kui teie CDN puhverdab personaliseeritud vastuse ja serveerib seda järgmistele külastajatele, läheb korraga katki kaks asja: personaliseerimine on nende külastajate jaoks vale ja puhverdatud variant on see, mida Googlebot uuesti roomates näeb. Iga enne CDN-i toimuv personaliseerimine vajab segmendisignaalile vary-päist või peab toimuma servas, kus iga külastaja saab oma otsuse puhvrit saastamata.

Tehniline seadistus, mis hoiab mõlemad töös

SEO-d arvestaval personaliseerimise seadistusel on mõned kohustuslikud osad. Kui need algusest peale õigesti teha, väldite ülaltoodud probleeme.

• Stabiilne vaikimisi kogemus. Tundmatutele külastajatele ja robotitele näidatav leht peab olema terviklik, sidus ja kajastama seda, millega soovite positsioone saada. See on teie SEO kanooniline sisu. Personaliseeritud variandid on selle peale tehtud vahetused, mitte selle asendused.
• Üks URL loogilise lehe kohta. Avaleht on üks URL, mitte viis. Valdkonnalehed on igaüks üks URL. Variandid kuvatakse sama URL-i sees, mitte eraldi päringustringiga versioonidel. See hoiab teie kanoonilised signaalid puhtad ja koondab lingiväärtuse.
• Serveripoolne või servas toimuv käivitamine ekraani ülaosa sisu jaoks. Sisu, mida Googlebot indekseerimiseks näha peab, peaks renderduma kliendipoolseid otsuseid ootamata. Ekraani allosa personaliseerimine võib toimuda pärast joonistamist.
• Robotite tuvastamine, mis kasutab vaikimisi baasversiooni. Enamikul isikupärastamisplatvormidel on lüliti, mis saadab Googlebotile ja teistele tuntud indekseerijatele vaikimisi kogemuse. Lülitage see sisse. See ei ole maskeerimine (cloaking), see on järjepidevus. Te tagate, et indekseeritud versioon vastab otsingu jaoks optimeeritud baasversioonile.
• Schema.org märgistus põhiversioonil. Struktureeritud andmed peavad viitama vaikesisule, mitte personaliseeritud variantidele. Kui teie juhtumiuuringute jaotis vahetub tegevusala järgi, peaks teie Article-skeem kirjeldama vaikimisi juhtumiuuringut, mitte parasjagu kuvatut.
• Vary-päised või servapõhine otsustamine. Iga CDN, mis asub teie lähteserveri ja külastaja vahel, peab teadma, millal vahemälust mööda minna. Puuduv vary-päis on kõige levinum põhjus, miks isikupärastus külastajate vahel lekib.

Lihtsalt öeldes: personaliseerimine on kiht otsingu jaoks optimeeritud baasversiooni peal, mitte selle asendus. Probleemid algavad siis, kui personaliseeritud kogemus muutub peamiseks ja vaikimisi versioon jääb järelmõtteks.

Milles enamik tiime eksib

Meie seisukoht: personaliseerimise suurim SEO-risk ei ole varjamine ega karistused. See on vale lähtepunktist alustamine.

Meeskonnad käsitlevad personaliseerimist kui viisi nõrga vaikimisi lehe parandamiseks. Nad loovad teadlikult üldise baasversiooni, eeldades, et see asendatakse enamiku külastajate jaoks niikuinii, ja vaatavad siis, kuidas positsioonid langevad. Baasversioon on see, mida Google indekseerib, ja suurem osa teie orgaanilisest liiklusest ei käivita kunagi ühtegi personaliseerimisreeglit. Kui vaikimisi leht on nõrk, on nõrgad ka positsioonid, ja liiklus, mida teie personaliseerimine oleks võinud konverteerida, ei jõua üldse kohale.

Soovitame vastupidist järjekorda: investeerige esmalt SEO jaoks võimalikult tugevasse üldisesse lehte ja lisage seejärel personaliseerimine selle peale. Meie avalehe personaliseerimise juhend ja ülevaade sellest, kuidas B2B veebilehe personaliseerimine toimib, teevad sama punkti konversiooni vaatenurgast.

Max Desiak, B2B SaaS SEO & AEO konsultant, kes töötab pika müügitsükliga kõrge ACV-ga kaubamärkidega, lisab, et pikkade müügitsüklite puhul on lähtetase veelgi olulisem: „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.“

Teine levinud viga on SEO ja personaliseerimise käsitlemine eraldi meeskondadena eraldi tegevuskavadega. Praktikas omab SEO-meeskond põhisisu, metasilte ja skeemi ning personaliseerimise meeskond nende peal olevaid variante. Kui nad ei koordineeri, võivad personaliseeritud variandid vaikselt eemalduda sellest, mida SEO-meeskond optimeeris, ning lõhe indekseeritud lehe ja personaliseeritud lehe vahel kasvab, kuni aruandlus näeb välja veider. Üks sümptom: SEO-meeskond imestab, miks kõrgel positsioonil olev leht halvasti konverteerib, samal ajal kui personaliseerimise meeskond imestab, miks sihtkontod nende jaoks loodud variante kunagi ei näe. Iga olulise lehe ühine omanik, kelle jaoks vaikimisi tekst on kokkulepitud tõeallikas, hoiab suurema osa sellest ära.

Praktiline test enne juurutamist

Enne kui käivitate personaliseerimise lehel, mis saab orgaanilist liiklust, tehke see kontroll. Avage leht inkognito aknas ilma küpsisteta. Seejärel avage see uuesti Googlebotina, kasutades kasutajaagendi vahetajat või Google Search Console’i URL-i kontrollimise tööriista. Võrrelge neid kahte. Põhisisu peaks ühtima. Kui ei ühti, on kas teie robotireegel vale või saastab teie vaikeversiooni personaliseerimisreegel, mis käivitub siis, kui ei peaks. Laiema programmi kohta vaadake meie juhendit müügitoru ümber planeeritud B2B SEO-st.

Järgmisena kontrollige renderdatud HTML-i, mitte toor-HTML-i. Kasutage Search Console'i URL-i kontrollimise tööriista, et näha, mida Googlebot tegelikult indekseeris. Kui kriitiline sisu, nagu hinnad, kliendilood või kliendiarvamused, ilmub renderdatud väljundisse alles pärast personaliseerimise lahendamist, on teil kliendipoolne ajastusprobleem. Viige see sisu serveri vastusesse.

Lõpuks kontrollige, et teie Core Web Vitals pole halvenenud. Kasutage PageSpeed Insightsi enne ja pärast isikupärastamise lubamist suure liiklusega lehel. Mõnesaja millisekundilist halvenemist on lihtne märkamata jätta, kui te seda ei otsi. Kui teie isikupärastamisplatvorm asub kriitilisel teel ja lisab latentsust, viige mittekiireloomulised otsused hilisemaks.

Kuidas see sobitub teiste personaliseerimise kaitsemeetmetega

SEO ohutus on üks kolmest töökorralduslikust murest, mis kerkib esile iga B2B personaliseerimise juurutamisel. Ülejäänud kaks on andmekaitse nõuetele vastamine, mida käsitlesime oma andmekaitse nõuetele vastavuse juhendis, ja visuaalne järjepidevus variantide vahel, mida käsitlesime oma postituses personaliseeritud B2B veebilehtede disainimustritest. Kõigil kolmel on sama põhiprintsiip: personaliseerimine peab olema turvaline kiht kindla aluse peal, mitte aluse distsipliini asendaja.

Mis tahes tööriista kasutate, kontrollige enne juurutamist nelja asja: tuntud roomajad saavad vaikimisi kogemuse, variandid asuvad samal URL-il (või kanoniseeritakse sellele), vaikeversioon renderdub segmendiotsust ootamata ja personaliseeritud vastuseid ei puhverdata kunagi teistele külastajatele. Kui kasutate Markettailorit, töötavad selle segmenteerimise reeglid ja A/B-testimine variantidena teie olemasolevatel URL-idel, nii et ülaltoodud kontrollid kehtivad otse; tehke igal juhul oma lehtedel inkognito vs URL-i kontrollimise test.

Kahe lause kokkuvõte

Veebisaidi personaliseerimine ei kahjusta SEO-t, kui alustate tugevast lähtetasemest, hoiate ühe URL-i loogilise lehe kohta ja lasete robotitel jõuda vaikimisi versioonini. See kahjustab SEO-t, kui tiimid käsitlevad personaliseerimist hea üldise sisu asendajana, jätavad tehnilise seadistuse vahele või lasevad kliendipoolsetel skriptidel viivitada Googleboti juurdepääsu olulisele sisule.

Kui isikupärastamisprojekti hoiab tagasi SEO-mure, tehke ülaltoodud käivituseelne test ühel lehel ja jagage tulemust SEO-meeskonnaga; see muudab üldise mure kontrollitavaks nimekirjaks. Andmete poole kohta vaadake, kuidas külastajate tuvastamine segmente toidab, või võrrelge pakette hinnalehel.

Korduma kippuvad küsimused

Kas personaliseerimine loetakse varjamiseks (cloaking)?

Ei, seni kuni eesmärk on külastajaid paremini teenindada ja Googlebot saab sama vaikimisi lehe, mille saaks tundmatu külastaja. Varjamine (cloaking) tähendab otsingumootoritele kasutajate nähtavast erineva sisu näitamist eesmärgiga positsioone manipuleerida. Juhtumiuuringu vahetamine tööstusharu järgi ei ole see.

Kas Googlebot peaks nägema lehe isikupärastatud versiooni?

Ei. Laske roomajatel alati vaikimisi kogemusele jõuda. Nii püsib indekseeritud sisu stabiilne ja leht on järjestatud selle järgi, mille jaoks te selle optimeerisite, mitte selle segmendi järgi, mida roomamise ajal juhtumisi näidati.

Kas kliendipoolne personaliseerimine kahjustab Core Web Vitalsit?

Võib küll. Skriptid, mis peidavad sisu, kuni segment on määratud, lükkavad edasi Largest Contentful Painti ja põhjustavad paigutuse nihkeid. Kuvage vaikesisu kohe, reserveerige vahetatavatele elementidele ruum ja laadige personaliseerimise skript asünkroonselt.

Kas Google personaliseerib otsingutulemusi?

Jah, peamiselt asukoha ja keele ning vähemal määral otsinguajaloo järgi. See on eraldi teema teie enda veebilehe personaliseerimisest. Kasutage järjestuste hindamiseks Search Console'i keskmist positsiooni, mitte oma brauserit.

Kas saan personaliseeritud lehti A/B-testida ilma SEO-d kahjustamata?

Jah. Google'i juhis veebilehtede testimiseks on kasutada variantide URL-idel rel=canonical'it, kasutada testivariantide puhul 301 asemel 302 ümbersuunamisi ja lõpetada testid, kui vastus on käes. Meie konversioonimäära optimeerimise juhend käsitleb, kuidas planeerida teste, mis mõistliku ajaga lõpevad.