Tämä uutinen on herättänyt keskustelua hakukoneoptimoijien keskuudessa. Ilmeisesti Google indeksoi myös tyyli- ja Javascript-tiedostoja. Uutinen ja siitä virinnyt keskustelu herättävät useita kysymyksiä.

Pystyykö Google tunnistamaan automaattisesti piilotekstin?

#piiloteksti {
color: white;
background-color: white;
}

Google on jo pitkään varoittanut käyttämästä sivuilla piilotekstiä eli tekstiä, jota ei näe muuten kuin lähdekoodia tutkimalla tai poistamalla CSS käytöstä. Tämä on vanha spämmäyskeino, joka on perinteisesti toteutettu tekstillä, jonka väri on sama tai lähes sama kuin taustaväri. Toisinaan piiloteksti on toteutettu jollakin seuraavista CSS-kikoista:

  • display: none
  • visibility: hidden
  • z-index: -1
  • text-indent: -9999px
  • font-size: 2px

Tällaisista hakukoneiden huijauksista on jääty useasti kiinni, mikä on johtanut poistamiseen Googlen indeksistä.

Monet webmasterit ovat kuitenkin olleet skeptisiä, kun on puhuttu Googlen kyvystä tunnistaa piilotekstiä, koska useat sitä väärinkäyttävät sivut ovat esiintyneet korkealla hakutuloksissa. Siitä on jääty kiinni, kun kilpailija, vihamies tai spämminvihaaja on ilmoittanut siitä Googlelle.

Nyt herää kysymys miten pitkälle Google menee tulkitessaan CSS-tiedostoa: voiko indeksistä lentää automaattisesti, vai tutkivatko Googlen työntekijät jokaisen tapauksen erikseen? Piilotekstille on nimittäin legitiimiäkin käyttöä…

Rankaiseeko Google saavutettavuudesta?

Yksi piilotekstin mahdollistama hyöty on saavutettavuus. Tämä tarkoittaa esimerkiksi tekstin piilottamista saman tekstin esittävien kuvien paikalle. Tällöin sokeiden puheselaimet ja tekstiselaimet pystyvät esittämään saman informaation kuin tekstiä esittävät kuvat.

Tällä hetkellä näyttää siltä, ettei esimerkiksi kuvallisen navigaation alle piilotettu tekstinavigaatio johda rangaistukseen. Mutta kuvitellaanpa että jokin flash- tai muuten hyvin graafinen sivusto esittäisi samalla sivulla pitkiä tekstinpätkiä sekä flashina/kuvina että piilotettuna tekstinä. Tulisiko rangaistus?

Käry voi myös käydä mikäli teksti poikkeaa vähänkin kuvallisesti esitetystä tekstistä. Tähän tosin tarvitaan ihmisen suorittamaa tarkastelua, jollei käytössä ole jokin CAPTCHA decoderin (kuten PWNtchan) kaltainen algoritmi, joka tunnistaa kuvissa olevan tekstin (tai sen että kuvassa ylipäätään on tekstiä). Vastaava ongelma liittyy myös kuvien alt-attribuutteihin.

Spämmääjät tosin tunkevat yleensä piilotekstiin pitkän listan toistuvia hakusanoja ja ehkä vielä niiden kirjoitusvirheitä sisältäviä muotoja – ja kuvittelevat että se toimii. Tällaisistä yrityksistä jäädään usein kiinni, kenties jopa CSS:n indeksoinnin seurauksena. Ehkäpä Googlen algoritmi kiinnittää muutenkin erityishuomiota sanalistoihin jotka eivät näytä syntaksiltaan luonnollisen kielen lauseilta.

Vinkki näkyvien sanalistojen käyttäjille: Google ei osaa suomea, joten voit huoletta kirjoittaa listasi esimerkiksi muotoon ”Sana1 sana2 sana3. Sana4 sana5 sana6 sana7.” Tällöin se muistuttaa rakenteeltaan normaalia tekstikappaletta (isot alkukirjaimet, pisteet lopussa, vaihtelevat sanamäärät ”lauseissa”). Hurja veikkaukseni on että sijoitus hakutuloksissa listan sanoilla voi hiukan parantua, jos listaa ei ole sijoitettu ja muotoiltu tyypillisen sanalistan näköiseksi. Ainakin listasi näyttää entistäkin hölmömmältä, etenkin kun Google näyttää siitä otteen hakutuloksissa.

Ovatko sivun sisäiset välilehdet ja vastaavat efektit pahasta?

Javasriptin ja piilotekstin yhdistelmällä voidaan tuottaa myös erilaisia navigaatiota ja näyttävyyttä tehostavia efektejä, esimerkiksi sivun sisäiset välilehdet. Välilehtiä on alettu käyttää yhä enemmän suurilla kaupallisilla sivustoilla (katso esimerkiksi IE7-selainta tyrkyttävä sivu). Periaatteessa sellaiset voidaan toteuttaa myös ajaxilla, mutta efektien nikottelu suuren liikennekuorman alla ei näyttäisi hyvältä.

Olisi outoa, että Google lähtisi taistelemaan tätä virtausta vastaan. Toki se voi jättää indeksoimatta sellaisen sisällön, joka ei näy ilman Javascript-efektiä (aluksi divillä siis esimerkiksi ”display: none”). Tai se voi antaa sille vähemmän painoa hakutuloksissa. Tätä on onneksi helppo testata.

Tunnistaako Google myös Javascript-linkit?

On löytynyt viitteitä, että Google tunnistaa ja seuraa myös Javascriptillä toteutettuja linkkejä.

Mihin Google käyttää CSS- ja Javascript tiedostoja?

Keskusteluissa on ehdotettu ainakin seuraavia tarkoituksia CSS- ja Javascript-tiedostojen indeksoinnille:

  • AdSense-tekstilinkkien viereen sijoitettujen kuvien löytäminen. Ovat vastoin AdSensen sääntöjä.
  • Mikä on linkkien asema suhteessa leipätekstiin? Korkein painoarvo on tekstin seassa olevilla linkeillä, vähemmän tärkeitä ovat esimerkiksi blogien Blogroll-linkit sivupalkissa.
  • Web-sivun aiotun ulkoasun järjestyksen selvittäminen. Sivujen sisältö voi näyttää olevan epäjärjestyksessä, kun CSS ei ole käytössä. Tälläinen tilanne esiintyy esimerkiksi sivuilla, joiden optimoijat ovat laittaneet vähemmän tärkeän sisällön ”position: absolute” -määritysten avulla HTML-koodin loppuun, koska he uskovat että järjestyksellä koodissa on merkitystä.
  • Javascript-uudelleenohjauksien löytäminen ja muu vastaava Javascriptin väärinkäyttö.
  • Googlen edustajat ovat luvanneet indeksoida myös ajax-sisältöä.
  • Epäasiallisen piilotekstin löytäminen.

Keskustelua

GoogleBot Requested a CSS File! – Updated – Viimeisimmän keskustelun aikaansaanut uutinen.

Google and CSS Files – Graywolf pohtii missä menee asiallisen piilotekstin raja.

Google and CSS Files, It’s Not What You’re Thinking – Jeremy Luebke epäilee, että Googlen algoritmit eivät paljoakaan välitä piilotekstistä vaan lähinnä Javasript-uudelleenohjauksista ja linkkien sijainnista sivulla. Ylä-, ala- ja sivupalkissa olevat linkit saisivat vähemmän painoarvoa niiden kohdesivujen rankkauksessa kuin tekstin keskellä sijaitsevat.

Is Google Sending GoogleBot CSS Hunting: Google Crawling CSS Files? – Search Engine Roundtable linkittää aikaisempiin uutisiin aiheesta. Kommenteissa Michael Martinez huomauttaa, että Google on hakenut JS- ja CSS-tiedostoja jo vuosien ajan.

Googlebot Crawling Css Files! – Cre8asite-foorumin keskustelu aiheesta.

Kommentoi