Jokainen B2B-markkinoija, joka alkaa rajata verkkosivujen personointiprojektia, saa lopulta saman kysymyksen joltakin SEO-tiimistä: ”Romahduttaako tämä orgaaniset sijoituksemme?” Huoli kehystetään yleensä cloakingin ympärille, ja se pysäyttää personointiprojektit lähes aina ennen kuin ne pääsevät edes alkuun. Pelkona on, että Googlebot näkee sivusta yhden version, ihmisvierailija toisen, ja Google rankaisee sivustoa ristiriitaisen sisällön näyttämisestä.
Lyhyesti: ei, jos se on rakennettu oikein. Googlen roskapostikäytännöt koskevat sijoitusten manipuloimiseksi muutettua sisältöä, eivät vierailijoille mukautettua sisältöä. Todelliset riskit ovat teknisiä: väärän variantin indeksointi, päällekkäiset URL-osoitteet, hidas tai estetty renderöinti ja välimuistivirheet. Ne aiheuttavat itse aiheutettuja sijoitusongelmia, joilla ei ole mitään tekemistä rangaistusten kanssa, ja niihin kannattaa varautua.
Tämä artikkeli käy läpi, mitä Googlen dokumentaatio sanoo, ne tapaukset, joissa personointi ja hakukoneoptimointi törmäävät, teknisen toteutuksen, joka pitää molemmat toimivina, sekä yleisimmän suunnitteluvirheen.
Lyhyt vastaus: miten personointi vaikuttaa hakukoneoptimointiin
Personointi vaikuttaa hakukoneoptimointiin vain sen sivun kautta, jonka Google indeksoi, ja sen latausnopeuden kautta. Jos indeksointirobotit ja ensikertalaiset saavat täydellisen oletussivun yhdessä URL-osoitteessa ja versiot vaihtavat sisältöä sen päälle hidastamatta sivua, sijoitukset eivät muutu. SEO-haitat johtuvat version indeksoitumisesta, versioiden jakamisesta eri URL-osoitteisiin, renderöinnin estämisestä tai yhden kävijän version tallentumisesta välimuistiin kaikille.
”Personointi ja hakukoneoptimointi” kätkee taakseen myös kaksi eri kysymystä, ja ne kannattaa erottaa:
- Google personoi omia tuloksiaan. Google mukauttaa tuloksia sijainnin, kielen ja rajallisesti hakuhistorian mukaan. Siksi kaksi ihmistä voi nähdä samalle haulle hieman eri sijoitukset. Et voi hallita sitä, ja useimmilla B2B-hakusanoilla se siirtää sijoituksia vain vähän. Seuraa sijoituksia neutraalista sijainnista ja käytä Search Consolen keskiarvoja omassa selaimessasi tehtyjen pistokokeiden sijaan.
- Sinä personoit verkkosivustoasi. Tätä tämän kirjoituksen loppuosa käsittelee: eri sisällön näyttämistä eri kävijöille omilla sivuillasi ja sitä, miten se tehdään heikentämättä sivujen sijoituksia.
Personoinnin tyypit ja niiden SEO-riski
Kaikkiin personoinnin muotoihin ei liity samaa riskiä. Arviomme yleisimmistä B2B-malleista:
| Personoinnin tyyppi | SEO-riski | Miksi | Turvallinen toteutus |
|---|---|---|---|
| Logojen, asiakastarinoiden tai suositusten vaihtaminen toimialan mukaan | Matala | Sivun pääaihe ja teksti pysyvät samoina | Oletus HTML:ssä, vaihto latauksen jälkeen tai reunalla |
| Otsikko- ja CTA-variantit segmenteittäin | Matala tai keskitaso | H1 on sijoitussignaali, joten oletus-H1:n on sisällettävä avainsana | Pidä avainsana oletus-H1:ssä; variantit lisäävät segmentin sanamuodon |
| Maantieteelliset tai kieliuudelleenohjaukset | Keskitaso | Googlebot indeksoi pääosin Yhdysvalloista eikä välttämättä koskaan näe muita versioita | Erilliset URL-osoitteet hreflangilla; ehdota uudelleenohjauksia, älä pakota |
| Variantit omissa kyselymerkkijono-URL-osoitteissaan | Keskitaso | Päällekkäiset sivut kilpailevat keskenään ja jakavat linkit | Aseta jokaisen version kanoniseksi oletus-URL |
| Kokonaisten osioiden piilottaminen tai korvaaminen joiltakin kävijöiltä | Korkea | Indeksoitu sisältö voi poiketa paljon siitä, mitä käyttäjät näkevät | Lisää osioita segmenteille, älä poista oletussisältöä |
| Googlebotille eri sisältö kuin kaikille ihmisille | Korkea (cloaking) | Vastaa Googlen cloaking-määritelmää | Botit saavat saman oletussivun kuin tuntematon vierailija |
Mitä Google oikeasti sanoo personoidusta sisällöstä
Googlen suhtautuminen personointiin on sallivampi kuin useimmat SEO-tiimit olettavat. Roskapostikäytännöissään Google määrittelee cloakingin seuraavasti: ”presenting different content to users and search engines with the intent to manipulate search rankings and mislead users.” Avainilmaus on ”to manipulate”. Kävijän ominaisuuksiin perustuva personointi, kuten toimialakohtaisen asiakastarinan näyttäminen terveydenhuoltoalan yrityksen kävijälle, ei ole cloakingia, koska sitä ei ole suunniteltu harhauttamaan Googlebotia tai manipuloimaan sijoituksia. Se on suunniteltu palvelemaan kävijää paremmin. Jos ulkopuolinen linkinrakennusyritys auditoi sivustosi, varmista, että se ymmärtää tämän eron ennen kuin se merkitsee personoituja sivuja ongelmallisiksi.
Googlen dynaamista renderöintiä käsittelevä sivu tekee samansuuntaisen huomion: "As long as your dynamic rendering produces similar content, Googlebot won't view dynamic rendering as cloaking." Sama sivu kutsuu dynaamista renderöintiä kiertotieksi, jota se ei enää suosittele, joten älä lue sitä suosituksena tarjota boteille erityisversiota. Turvallinen tulkinta: Googlebotin saaman sisällön pitää olla sama kuin tuntemattoman ihmiskävijän.
Kieli- ja maaversioiden osalta Googlen ohje monialueellisten sivustojen hallinnasta neuvoo olemaan ohjaamatta käyttäjiä automaattisesti kielen perusteella ja huomauttaa, että suurin osa Googlen indeksoinneista lähtee Yhdysvalloista, joten pelkästään sijaintikohtaista sisältöä ei ehkä koskaan indeksoida. Käytä sen sijaan erillisiä URL-osoitteita ja hreflangia.
Käytännössä hakusijoituksia heikentävät tekniset virheet: väärän variantin indeksointi, kanonisten signaalien rikkoutuminen tai Googlebotin estäminen tärkeästä sisällöstä.
Missä personointi ja hakukoneoptimointi oikeasti törmäävät
Kitkakohdat ovat suppeampia kuin useimmat tiimit odottavat. Viisi kaavaa kattaa suurimman osan SEO-ongelmista, joita personoinnin käyttöönotto voi aiheuttaa.
1. Personoidun version indeksointi kanoniseksi versioksi
Esimerkki: tiimi rakentaa personoidun etusivun viidellä toimialavariantilla. Palvelin sattuu tarjoamaan terveydenhuollon variantin, kun Googlebot indeksoi, ja yhtäkkiä juuri tuo toimialakohtainen versio sijoittuu hakutuloksissa. Kaikki brändinimelläsi hakevat laskeutuvat sivulle, joka on rakennettu segmentille, johon he eivät kuulu.
Ratkaisu ei ole piilottaa variantteja Googlebotilta. Ratkaisu on varmistaa, että oletuskokemus, joka näytetään tuntemattomille tai luokittelemattomille kävijöille, on myös se, minkä Googlebot johdonmukaisesti näkee. Bottien pitäisi aina päätyä oletukseen, ei koskaan segmenttiin.
2. Väärään URL-osoitteeseen osoittavat canonical-tagit
Tiimit antavat joskus jokaiselle personoidulle variantille oman URL-osoitteen ( /?segment=healthcare, /?segment=finance) asettamatta canonical-tageja oikein. Googlen on silloin valittava, minkä variantin se indeksoi, ja valittu on harvoin se, jonka haluat sijoittuvan. Jos haluat personointivarianttien sijaitsevan erillisissä URL-osoitteissa, osoita jokaisen variantin canonical-tagi oletusversioon. Jos haluat yhden URL-osoitteen, joka muuttuu kävijän mukaan, pidä se yhtenä URL-osoitteena ja tarjoa sisältö palvelinpuolella tai selainpuolen renderöinnillä, joka hydratoituu indeksoinnin jälkeen.
3. Hidas Time-to-First-Byte palvelinpuolen personoinnin vuoksi
Sen päättäminen, mitä sisältöä renderöidään ennen vastaamista, lisää viivettä jokaiseen pyyntöön, jos personointikutsu on kriittisellä polulla. Core Web Vitals huomaa tämän: Google pitää Largest Contentful Paint -arvoa hyvänä, kun se on enintään 2,5 sekuntia, ja päätösvaihe, joka työntää tärkeät sivut sen yli, haittaa sekä käyttäjiä että sivukokemuksen signaaleja. Mittaa time to first byte personointikutsun kanssa ja ilman ennen käynnistystä. Ratkaisu on siirtää ei-kriittiset personointipäätökset edgeen tai selaimeen ja varmistaa, että toimittajasi tukee aitoa edge-suoritusta eikä alueellista keskitinreititystä.
4. Selainpuolen personointi, joka estää renderöinnin
Asiakaspuolen personointiskriptit, jotka estävät pääsäikeen segmenttejä hakiessaan, aiheuttavat asettelun siirtymiä ja viivästynyttä interaktiivisuutta. Googlebot pystyy renderöimään JavaScriptiä, mutta se priorisoi nopeita, estämättömiä skriptejä. Jos personointikirjastosi odottaa segmenttipäätöstä ennen hero-osion näyttämistä, Googlebot voi indeksoida tyhjän hero-osion tai ohittaa sisällön kokonaan. Käytä estämättömiä segmenttipäätöksiä ja oletustilaa, joka renderöityy heti ja vaihtaa sisällön, kun segmentti selviää. Tilan varaamisen mekaniikasta, jottei vaihdettu lohko heiluttele sivua, katso tämä opas Cumulative Layout Shiftin ehkäisemiseen.
5. CDN-välimuisti törmää personoituihin vastauksiin
Jos CDN tallentaa välimuistiin personoidun vastauksen ja tarjoaa sen seuraaville kävijöille, kaksi asiaa rikkoutuu kerralla: personointi on väärä noille kävijöille, ja välimuistissa oleva variantti päätyy siksi, minkä Googlebot näkee uudelleenindeksoinnissa. Kaikki ennen CDN:ää tapahtuva personointi tarvitsee segmenttisignaalille vary-otsakkeen, tai sen on tapahduttava reunaverkossa, jossa jokainen kävijä saa oman päätöksensä välimuistia saastuttamatta.
Tekninen asetelma, joka pitää molemmat toiminnassa
Hakukoneoptimointia kunnioittavassa personoinnissa on muutama pakollinen osa. Kun ne tehdään oikein heti alussa, yllä mainitut ongelmat vältetään.
- Vakaa oletuskokemus. Tuntemattomille vierailijoille ja boteille tarjottavan sivun on oltava täydellinen, johdonmukainen ja vastattava sitä, millä haluat sijoittua. Tämä on SEO:n kanoninen sisältösi. Personoidut variantit ovat vaihtoja sen päällä, eivät sen korvikkeita.
- Yksi URL loogista sivua kohden. Etusivu on yksi URL, ei viisi. Toimialasivuilla on kullakin yksi URL. Variantit renderöidään saman URL-osoitteen sisällä, ei omiin kyselymerkkijonolla jatkettuihin versioihin. Tämä pitää kanoniset signaalit puhtaina ja keskittää linkkiarvon.
- Palvelinpuolen tai reunapalvelimen suoritus näkyvän alueen sisällölle. Sisällön, joka Googlebotin pitää nähdä indeksointia varten, tulisi renderöityä odottamatta asiakaspuolen päätöksiä. Näkyvän alueen alapuolinen personointi voi ajautua piirtämisen jälkeen.
- Bottien tunnistus, joka palauttaa perusversion. Useimmissa personointialustoissa on asetus, joka näyttää Googlebotille ja muille tunnetuille indeksointiroboteille oletuskokemuksen. Ota se käyttöön. Tämä ei ole cloakingia vaan johdonmukaisuutta. Varmistat, että indeksoitu versio vastaa perusversiota, jonka olet optimoinut hakua varten.
- Schema.org-merkintä perusversioon. Rakenteisen datan on viitattava oletussisältöön, ei personoituihin variantteihin. Jos asiakastarinaosiosi vaihtuu toimialan mukaan, Article-skeemasi pitää kuvata oletusasiakastarinaa, ei sillä hetkellä näytettyä.
- Vary-otsakkeet tai reunalla tehtävä päätöksenteko. Jokaisen alkuperäpalvelimen ja kävijän välissä olevan CDN:n on tiedettävä, milloin välimuisti ohitetaan. Puuttuva vary-otsake on yleisin syy siihen, että personointi vuotaa kävijältä toiselle.
Yksinkertaisesti: personointi on kerros hakukoneoptimoidun perustason päällä, ei sen korvike. Ongelmat alkavat, kun personoidusta kokemuksesta tulee ensisijainen ja oletusversio jää jälkiajatukseksi.
Missä useimmat tiimit menevät vikaan
Näkemyksemme: personoinnin suurin SEO-riski ei ole cloaking tai rangaistukset. Se on väärästä lähtötasosta aloittaminen.
Tiimit käyttävät personointia heikon oletussivun paikkaamiseen. Ne rakentavat tarkoituksella geneerisen perustason olettaen, että se korvataan useimmilla vierailijoilla joka tapauksessa, ja katsovat sitten sijoitusten putoavan. Google indeksoi juuri perustason, eikä suurin osa orgaanisesta liikenteestäsi koskaan laukaise personointisääntöä. Jos oletusversio on heikko, sijoitukset ovat heikkoja, eikä liikennettä, jonka personointisi olisi voinut konvertoida, tule lainkaan.
Suosittelemamme järjestys on päinvastainen: panosta ensin mahdollisimman vahvaan geneeriseen sivuun hakukoneoptimointia varten ja lisää sitten personointi sen päälle. Etusivun personoinnin oppaamme ja läpikäyntimme siitä, miten B2B-verkkosivuston personointi toimii, sanovat saman konversion näkökulmasta.
Max Desiak, B2B SaaS -yritysten SEO- ja AEO-konsultti, joka työskentelee korkean ACV:n ja pitkien myyntisyklien brändien kanssa, lisää, että lähtötason merkitys kasvaa entisestään, kun myyntisyklit ovat pitkiä: "Ostoryhmät päätyvät yleensä ensin oletussivullesi orgaanisen tai tekoälyhaun kautta, ennen kuin mitään segmenttisignaalia on olemassa. Sivun on kannettava avainsana ja argumentti omillaan, koska personointi voi parantaa vain liikennettä, jonka olet jo ansainnut."
Toinen yleinen virhe on kohdella SEO:ta ja personointia erillisinä tiiminä, joilla on omat tiekarttansa. Käytännössä SEO-tiimi omistaa perussisällön, metatagit ja skeeman, ja personointitiimi omistaa niiden päälle rakennetut variantit. Jos ne eivät koordinoi, personoidut variantit voivat huomaamatta ajautua pois siitä, mitä SEO-tiimi optimoi, ja ero indeksoidun ja personoidun sivun välillä kasvaa, kunnes raportointi näyttää oudolta. Yksi oire: SEO-tiimi ihmettelee, miksi kärkisijoilla oleva sivu konvertoi huonosti, ja personointitiimi ihmettelee, miksi kohdeasiakkuudet eivät koskaan näe niille rakennettuja variantteja. Yhteinen omistaja jokaiselle tärkeälle sivulle ja oletusteksti sovittuna totuuden lähteenä ehkäisevät suurimman osan tästä.
Käytännön testi ennen laajaa käyttöönottoa
Ennen kuin käynnistät personointia sivulla, joka saa orgaanista liikennettä, tee tämä tarkistus. Avaa sivu incognito-ikkunassa ilman evästeitä. Avaa se sitten uudelleen Googlebotina user-agent-vaihtimella tai Google Search Consolen URL-tarkistustyökalulla. Vertaa näitä kahta. Pääsisällön pitäisi olla sama. Jos se ei ole, joko bottisääntösi on pielessä tai oletusversiosi saastuu personointisäännöstä, joka laukeaa, kun sen ei pitäisi. Laajemmasta ohjelmasta kerrotaan oppaassamme myyntiputken ympärille suunnitellusta B2B-hakukoneoptimoinnista.
Tarkista seuraavaksi renderöity HTML, ei raakaa HTML:ää. Käytä Search Consolen URL-tarkistustyökalua nähdäksesi, mitä Googlebot todella indeksoi. Jos kriittinen sisältö, kuten hinnoittelu, asiakastarinat tai suositukset, näkyy renderöidyssä tuloksessa vasta personoinnin ratkettua, sinulla on selainpuolen ajoitusongelma. Siirrä tuo sisältö palvelimen vastaukseen.
Varmista lopuksi, etteivät Core Web Vitals -arvosi ole heikentyneet. Käytä PageSpeed Insightsia ennen ja jälkeen personoinnin käyttöönoton paljon liikennettä saavalla sivulla. Muutaman sadan millisekunnin heikennys jää helposti huomaamatta, jos et etsi sitä. Jos personointialustasi on kriittisellä polulla ja lisää viivettä, siirrä kiireettömät päätökset myöhemmäksi.
Miten tämä sopii yhteen muiden personoinnin suojausten kanssa
Hakukoneoptimoinnin turvallisuus on yksi kolmesta operatiivisesta huolenaiheesta, jotka nousevat esiin jokaisessa B2B-personoinnin käyttöönotossa. Kaksi muuta ovat tietosuojan noudattaminen, jota käsittelimme tietosuojaoppaassamme, ja varianttien visuaalinen johdonmukaisuus, jota käsittelimme kirjoituksessamme personoitujen B2B-verkkosivustojen suunnittelumalleista. Kaikilla kolmella on sama perusperiaate: personoinnin on oltava turvallinen kerros vankan perustan päällä, ei korvike perustan kurinalaisuudelle.
Käytitpä mitä työkalua tahansa, tarkista neljä asiaa ennen käyttöönottoa: tunnetut hakurobotit saavat oletuskokemuksen, variantit ovat samassa URL-osoitteessa (tai kanonisoivat siihen), oletus renderöityy odottamatta segmenttipäätöstä, eikä personoituja vastauksia koskaan tallenneta välimuistiin muille kävijöille. Jos käytät Markettailoria, sen segmentointisäännöt ja A/B-testaus toimivat variantteina olemassa olevissa URL-osoitteissasi, joten yllä olevat tarkistukset pätevät suoraan; tee incognito- ja URL-tarkistusvertailu omilla sivuillasi joka tapauksessa.
Kahden lauseen yhteenveto
Verkkosivujen personointi ei heikennä hakukoneoptimointia, kun lähdet vahvasta perustasosta, pidät yhden URL-osoitteen loogista sivua kohden ja annat bottien päätyä oletukseen. Se heikentää hakukoneoptimointia, kun tiimit pitävät personointia hyvän yleisen sisällön korvikkeena, ohittavat tekniset asetukset tai antavat selainpuolen skriptien viivästyttää Googlebotin pääsyä kriittiseen sisältöön.
Jos hakukoneoptimointihuoli jarruttaa personointiprojektia, tee yllä kuvattu julkaisua edeltävä testi yhdellä sivulla ja jaa tulos SEO-tiimin kanssa; se muuttaa yleisen huolen tarkistettavaksi listaksi. Datapuolesta katso, miten kävijätunnistus syöttää segmenttejä, tai vertaa paketteja hinnoittelusivulla.
Usein kysytyt kysymykset
Lasketaanko personointi cloakingiksi?
Ei, kunhan tarkoitus on palvella vierailijoita paremmin ja Googlebot saa saman oletussivun kuin tuntematon vierailija. Cloaking on hakukoneille näytettävää sisältöä, joka eroaa käyttäjien näkemästä, sijoitusten manipuloimiseksi. Asiakastarinan vaihtaminen toimialan mukaan ei ole sitä.
Pitäisikö Googlebotin nähdä sivun personoitu versio?
Ei. Anna indeksointirobottien päätyä aina oletuskokemukseen. Näin indeksoitu sisältö pysyy vakaana ja sivu sijoittuu sillä, mitä optimoit, eikä sillä segmentillä, joka sattui näkymään indeksoinnin aikana.
Heikentääkö selainpuolen personointi Core Web Vitals -arvoja?
Voi heikentää. Skriptit, jotka piilottavat sisällön siihen asti, kunnes segmentti on selvitetty, viivästävät Largest Contentful Paint -arvoa ja aiheuttavat asettelun siirtymiä. Näytä oletusversio heti, varaa tila vaihdettaville elementeille ja lataa personointiskripti asynkronisesti.
Personoiko Google hakutulokset?
Kyllä, pääasiassa sijainnin ja kielen mukaan ja vähäisemmässä määrin hakuhistorian mukaan. Se on eri aihe kuin oman verkkosivustosi personointi. Arvioi sijoituksia Search Consolen keskimääräisen sijainnin, älä oman selaimesi perusteella.
Voinko A/B-testata personoituja sivuja vahingoittamatta hakukoneoptimointia?
Kyllä. Googlen ohje verkkosivustojen testaukseen on käyttää rel=canonical-tagia versioiden URL-osoitteissa, käyttää testiversioissa 302- eikä 301-uudelleenohjauksia ja lopettaa testit, kun niistä on saatu vastaus. Konversio-optimoinnin oppaamme kertoo, miten suunnitellaan testejä, jotka valmistuvat kohtuullisessa ajassa.