Tapaustutkimus: Kuinka evästehirviö söi 22 % näkyvyydestämme


Kirjoittajan näkemykset ovat täysin hänen omiaan (lukuun ottamatta epätodennäköistä hypnoositapahtumaa), eivätkä ne välttämättä aina heijasta Mozin näkemyksiä.

Viime vuonna Homeday – yksi johtavista kiinteistöteknologiayrityksistä Saksassa – teki päätöksen siirtyä uuteen sisällönhallintajärjestelmään (CMS). Siirron tavoitteina olivat muun muassa sivun nopeuden lisääminen ja nykyaikaisen, tulevaisuudenkestävän verkkosivuston luominen kaikilla tarvittavilla ominaisuuksilla. Yksi siirtymisen tärkeimmistä motiiveista oli mahdollistaa sisällöntuottajien vapaampi työskentely sivujen luomisessa ilman kehittäjien apua.

Arvioimme useita CMS-vaihtoehtoja, ja päädyimme Contentfuliin sen nykyaikaisen teknologiapinon vuoksi, jolla on ylivoimainen kokemus sekä toimittajille että kehittäjille. Teknisestä näkökulmasta Contentful, päättömänä sisällönhallintajärjestelmänä, antaa meille mahdollisuuden valita, mitä renderöintistrategiaa haluamme käyttää.

Toteutamme tällä hetkellä siirtoa useissa vaiheissa tai aalloissa vähentääksemme riskiä ongelmista, joilla on laajamittainen negatiivinen vaikutus. Ensimmäisen aallon aikana kohtasimme ongelman evästeiden hyväksymisessämme, mikä johti lähes 22 prosentin näkyvyyden heikkenemiseen viidessä päivässä. Tässä artikkelissa kuvailen ongelmia, joita kohtasimme tämän ensimmäisen siirtoaallon aikana, ja kuinka ratkaisimme ne.

Ensimmäisen testiaallon asettaminen

Ensimmäiselle testiaaltolle valitsimme 10 SEO-sivua, joilla oli paljon liikennettä mutta alhaiset tulosprosentit. Perustimme infrastruktuurin näiden 10 sivun raportointiin ja seurantaan:

  • Sijoituksen seuranta osuvimpien avainsanojen osalta

  • SEO hallintapaneeli (DataStudio, Moz Pro, SEMRush, Search Console, Google Analytics)

  • Säännölliset ryömitykset

Kun kattava suunnittelu- ja testausvaiheessasiirsimme ensimmäiset 10 SEO-sivua uuteen sisällönhallintajärjestelmään joulukuussa 2021. Vaikka testausvaiheessa esiintyi useita haasteita (pidennetyt latausajat, suurempi HTML-dokumenttiobjektimalli jne.), päätimme julkaista, koska emme nähneet suurta esto ja halusimme siirtää ensimmäisen testiaallon ennen joulua.

Ensimmäinen suoritusarvostelu

Olemme erittäin innoissamme siirron ensimmäisestä vaiheesta, joten tarkastelimme siirrettyjen sivujen suorituskykyä seuraavana päivänä.

Se, mitä näimme seuraavaksi, ei todellakaan miellyttänyt meitä.

Yön aikana seurattujen avainsanojen näkyvyys siirretyillä sivuilla laski 62,35 prosentista 53,59 prosenttiin — menetimme 8,76 % näkyvyydestä yhdessä päivässä!

Tämän jyrkän sijoitusten pudotuksen seurauksena suoritimme toisen laajan testikierroksen. Testasimme muun muassa kattavuus-/indeksointiongelmia, kaikkien sisällönkuvauskenttien sisällyttämistä, strukturoitua dataa, sisäisiä linkkejä, sivun nopeutta ja mobiiliystävällisyyttä.

Toinen suoritusarviointi

Kaikilla artikkeleilla oli välimuistin päivämäärä siirron jälkeen, ja sisältö oli täysin indeksoitu ja Google luki sen. Lisäksi voisimme sulkea pois useita siirtymisen riskitekijöitä (URL-osoitteiden, sisällön, sisällönkuvauskenttien, asettelun jne. muutokset) virhelähteinä, koska muutoksia ei ole tapahtunut.

Seuraavien avainsanojemme näkyvyys putosi jälleen 40,60 prosenttiin seuraavien päivien aikana, joten se laski yhteensä lähes 22 % viiden päivän sisällä. Tämä näkyi myös selvästi verrattuna seurattujen avainsanojen kilpailuun (tässä “arvioitu liikenne”), mutta näkyvyys näytti vastaavalta.

Tiedot SEMRushista, määritetty avainsanajoukko siirrettyjen sivujen seuratuille avainsanoille

Koska muut siirtymisen riskitekijät ja Google-päivitykset oli jätetty pois virhelähteistä, sen oli ehdottomasti oltava tekninen ongelma. Liian paljon JavaScriptiä, alhaiset Core Web Vitals -pisteet tai suurempi, monimutkaisempi asiakirjaobjektimalli (DOM) voivat kaikki olla mahdollisia syitä. DOM edustaa sivua objekteina ja solmuina, jotta ohjelmointikielet, kuten JavaScript, voivat olla vuorovaikutuksessa sivun kanssa ja muuttaa esimerkiksi tyyliä, rakennetta ja sisältöä.

Keksimurujen perässä

Meidän piti tunnistaa ongelmat mahdollisimman nopeasti ja korjata vikoja ja minimoida negatiiviset vaikutukset ja liikenteen väheneminen. Saimme vihdoin ensimmäisen varsinaisen vihjeen siitä, mikä tekninen syy voisi olla syynä, kun yksi työkalumme osoitti meille, että korkean ulkoisen linkityksen sivujen määrä sekä sivujen määrä, joiden sisältö on maksimikokoinen, kasvoi. On tärkeää, että sivut eivät ylitä enimmäissisällön kokoa, koska sivuja, joilla on erittäin paljon sisältöä, ei välttämättä indeksoida kokonaan. Korkean ulkoisen linkityksen kannalta on tärkeää, että kaikki ulkoiset linkit ovat luotettavia ja olennaisia ​​käyttäjille. Oli epäilyttävää, että ulkoisten linkkien määrä kasvoi juuri näin.

Useita URL-osoitteita, joissa on paljon ulkoisia linkkejä (yli 10)
Sellaisten URL-osoitteiden määrä, jotka ylittävät määritetyn sisällön enimmäiskoon (51 200 tavua)

Molemmat mittarit olivat suhteettoman korkeita verrattuna siirrettävien sivujen määrään. Mutta miksi?

Tarkastettuamme, mitä ulkoisia linkkejä oli lisätty siirretyille sivuille, huomasimme, että Google luki ja indeksoi sivua evästeen suostumuslomake kaikille siirretyille sivuille. Teimme sivustohaun, tarkistimme evästeen suostumuksen sisällön ja näimme teoriamme vahvistuvan:

Sivustohaku vahvisti, että Google indeksoi evästeen suostumuksen

Tämä johti useisiin ongelmiin:

  1. Jokaiselle sivulle luotiin tonnia päällekkäistä sisältöä evästeen suostumuslomakkeen indeksoinnin vuoksi.

  2. Siirrettyjen sivujen sisällön koko kasvoi rajusti. Tämä on ongelma, koska sivuja, joilla on erittäin paljon leipäsisältöä, ei välttämättä indeksoida kokonaan.

  3. Ulkoisten lähtevien linkkien määrä kasvoi rajusti.

  4. Katkelmamme osoittivat yhtäkkiä päivämäärän SERP:issä. Tämä ehdottaisi blogia tai uutisartikkelia, kun taas useimmat Homeday-artikkelit ovat ikivihreitä. Lisäksi päivämäärän ilmestymisen vuoksi metakuvaus leikattiin pois.

Mutta miksi tämä tapahtui? Palveluntarjoajamme Cookiebotin mukaan hakukoneiden indeksointirobotit pääsevät verkkosivustoille, jotka simuloivat täydellistä suostumusta. Näin ollen he saavat pääsyn kaikkeen sisältöön ja Indeksointirobotti ei indeksoi evästeen suostumusbannereita.

Joten miksi tämä ei koske siirrettyjä sivuja? Indeksoimme ja renderöimme sivut eri käyttäjäagenttien avulla, mutta emme silti löytäneet jälkeäkään Cookiebotista lähdekoodista.

Google DOM:ien tutkiminen ja ratkaisun etsiminen

Siirretyt sivut renderöidään dynaamisilla tiedoilla, jotka tulevat Contentfulista ja laajennuksista. Laajennukset sisältävät vain JavaScript-koodin, ja joskus ne tulevat kumppanilta. Yksi näistä laajennuksista oli evästeenhallintakumppani, joka hakee evästeen suostumus-HTML-koodin koodipohjamme ulkopuolelta. Tästä syystä emme alun perin löytäneet jälkeäkään evästeen suostumuksen HTML-koodista HTML-lähdetiedostoista. Näimme suuremman DOM:n, mutta jäljitimme sen Nuxtin oletusarvoiseen, monimutkaisempaan, suurempaan DOM:iin. Nuxt on JavaScript-kehys, jonka kanssa työskentelemme.

Vahvistaaksemme, että Google luki evästeen suostumusbannerin kopion, käytimme Google Search Consolen URL-tarkastustyökalua. Vertasimme siirretyn sivun DOM:ia siirtämättömän sivun DOM:iin. Siirretyn sivun DOM:sta löysimme vihdoin evästeen suostumuksen sisällön:

Löysimme siirretyn sivun DOM:sta evästeen suostumuksen sisällön

Jotain muuta, joka kiinnitti huomiomme, olivat vanhoille sivuillemme ladatut JavaScript-tiedostot verrattuna siirretyille sivuillemme ladattuihin tiedostoihin. Verkkosivustollamme on kaksi kolmannen osapuolen tarjoamaa evästeen suostumusbannerin skriptiä: toinen näyttää bannerin ja nappaa suostumuksen (uc) ja toinen, joka tuo bannerin sisällön (cd).

  • Ainoa vanhoille sivuillemme ladattu skripti oli uc.jsjoka on vastuussa evästeen suostumusbanneri. Se on yksi skripti, jota tarvitsemme jokaisella sivulla käsitelläksemme käyttäjän suostumusta. Se näyttää evästeen suostumusbannerin indeksoimatta sisältöä ja tallentaa käyttäjän päätöksen (jos hän suostuu tai eri mieltä evästeiden käytöstä).

  • Siirretyille sivuille oli uc.js:n lisäksi myös a cd.js tiedoston lataus. Jos meillä on sivu, jolla haluamme näyttää käyttäjälle lisätietoja evästeistämme ja indeksoida evästetiedot, meidän on käytettävä cd.js-tiedostoa. Ajattelimme, että molemmat tiedostot ovat riippuvaisia ​​toisistaan, mikä ei ole oikein. uc.js voi toimia yksin. Cd.js-tiedosto oli syy siihen, miksi evästebannerin sisältö renderöitiin ja indeksoitiin.

Sen löytäminen kesti hetken, koska luulimme, että toinen tiedosto oli vain ennakkovaatimus ensimmäiselle. Päätimme, että ladatun cd.js-tiedoston poistaminen olisi ratkaisu.

Suorituskykyarviointi ratkaisun käyttöönoton jälkeen

Päivänä, jolloin poistimme tiedoston, avainsanojemme näkyvyys oli 41,70 %, mikä oli edelleen 21 % pienempi kuin ennen siirtoa.

Kuitenkin seuraavana päivänä tiedoston poistamisen jälkeen näkyvyytemme nousi 50,77 prosenttiin ja seuraavana päivänä se oli melkein palannut normaaliksi 60,11 prosenttiin. Arvioitu liikenne käyttäytyi samalla tavalla. Mikä helpotus!

Pian ratkaisun käyttöönoton jälkeen orgaaninen liikenne palasi siirtoa edeltävälle tasolle

Johtopäätös

Voin kuvitella, että monet hakukoneoptimoijat ovat käsitelleet tämän kaltaisia ​​pieniä ongelmia. Se vaikuttaa triviaalilta, mutta johti merkittävästi näkyvyyden ja liikenteen heikkenemiseen muuton aikana. Tästä syystä suosittelen siirtymistä aalloilla ja riittävän ajan estämistä teknisten virheiden tutkimiseen ennen ja jälkeen migraation. Lisäksi on erittäin tärkeää seurata tarkasti sivuston suorituskykyä siirron jälkeisten viikkojen aikana. Nämä ovat ehdottomasti tärkeimmät otokseni tästä muuttoliikkeestä. Toisen migraatioaallon saimme juuri päätökseen toukokuun 2022 alussa ja voin todeta, että toistaiseksi ei ole ilmennyt suuria bugeja. Meillä on vielä kaksi aaltoa ja saamme siirron päätökseen toivottavasti onnistuneesti kesäkuun 2022 loppuun mennessä.

Siirrettyjen sivujen suorituskyky on nyt melkein palannut normaaliksi, ja jatkamme seuraavalla aallolla.



Source link

About the Author

Leave a Reply

Your email address will not be published. Required fields are marked *

You may also like these

This error message is only visible to WordPress admins

Error: No feed found.

Please go to the Instagram Feed settings page to create a feed.