Hakukoneoptimointi

Viime aikoina on ollut paljon puhetta ns. porttisivuista (doorway pages). Porttisivuista on englannin kielellä muitakin eri nimityksiä, kuten gateway pages, landing pages, jump pages ja bridge pages. Mitä nämä porttisivut sitten oikeastaan ovatkaan?

Jos lähtisimme kuvaamaan porttisivua lyhyesti, olisi määritelmä seuraava:

Sivu, jonka tarkoitus on tuoda varsinaiselle sivustolle lisää liikennettä.

Tämä ei tosin kerro vielä mitään, joten menkäämme hieman syvemmälle. Porttisivut voidaan jakaa kolmeen kategoriaan:

Niihin, jotka näyttävät “oikeilta” sivuilta, mutta käyttäjä päätyy varsinaiselle sivustolle vasta klikattuaan linkkiä porttisivulta. Esimerkkinä tälle tapaukselle voisimme ottaa tämän blogin; Rekisteröin uuden domainin (tai luon alidomainin), jolle kopioin ulkoasun sekä yhden sivun tästä blogista. Muokkaan sivun tekstisisällön erittäin avainsanarikkaaksi ja muutan kaikki linkit osoittamaan tähän blogiin. Tässä vaiheessa normaali webissä surffaaja luulee tosissaan olevansa tällä sivustolla, vaikka todellisuudessa hän on sivusto.com -sivustolla (tai alidomainilla). Vasta klikattuaan linkkiä sivusto.com:ssa hän päätyy hakukoneoptimointia.com:iin. Näitä sivuja kun teen useamman sata kappaletta, on kävijätulva varma, vai mitä? ;)

Tätä lähellä on myös toinen tapa, jota muun muassa eräs hakukoneoptimointia ammattitaidolla tarjoava firma harrasti. Tässäkin tapauksessa voidaan rekisteröidä uusia domaineja tai luoda alidomaineja tarkoitusta varten. Erona tässä on se, että porttisivuja ei jakseta “piilotella” vaan lyödään ne heti täyteen tuhansia avainsanoja ja lisätään linkki varsinaiselle sivustolle. Nimitetään näitä vaikka laiskan miehen porttisivuiksi.

Kolmas ja yleisimmin käytetty tapa on luoda samanlaisia sivuja kuin edellisessä tapauksessa. Näissä erotuksena on tosin se, että vierailija ohjataan samantien varsinaiselle sivulle käyttämällä erilaisia uudelleenohajuksia. Uudelleenohjauksena voidaan käyttää muun muassa HTML meta -refreshia, javascript -uudelleenohjausta tai kuuluisaa cloaking -tekniikkaa.

Näiden kolmen uudelleenohjauksen erona on se, että kaksi ensimmäistä ovat ihmissilmin havaittavia lähdekoodista, kun taas cloaking tapahtuu palvelinpuolella. Näin ollen sen havaitseminen on erittäin vaikeaa. Hyvä keino tunnistaa näitä sivuja hakukonetuloksista on tarkkailla niiden kuvauksia ja etsiä sivulta kyseistä tekstinpätkää. Mikäli kuvauksessa olevaa tekstiä ei sivulta löydy ja välimuistiin tallentaminen on hakukoneilta kielletty, on sivulla todenäköisesti käytetty cloaking -tekniikkaa näyttämään hakukoneille eri sivua kuin ihmisvierailijalle. Lisätietoa cloaking tekniikasta löytyy täältä.

Porttisivuja on ollut miltei niin kauan kuin hakukoneitakin, tosin nykyisin niitä käyttävät lähinnä vain pornosivujen omistajat sekä epäeettisesti toimivat hakukoneoptimoijat ja webmasterit.

Tätä blogia lukeneille on varmaan jo käynyt ilmi ankkuritekstin merkitys linkeissä ja se, että niissä tulisi olla myös sinulle tai linkin vastaanottajalle tärkeitä avainsanoja. Menkäämme kuitenkin hieman pidemmälle ankkuritekstien kanssa.

Allaolevassa esimerkissä on esitetty viisi esimerkkiä linkin ankkuritekstistä. Linkkien saaja, Teuvo, keskittyy sekä sivujen suunnitteluun, että markkinointiin. Minkä näistä linkeistä sinä valitsisit parhaimpana Teuvolle?

sivujen suunnittelu ja markkinointi hoituvat Teuvon neuvoilla
sivujen suunnittelu ja markkinointi hoituvat Teuvon neuvoilla
sivujen suunnittelu ja markkinointi hoituvat Teuvon neuvoilla
sivujen suunnittelu ja markkinointi hoituvat Teuvon neuvoilla
sivujen suunnittelu ja markkinointi hoituvat Teuvon neuvoilla

Moni ei tule ajatelleeksi sitä, että liika avainsanojen viljely linkkiin käytännössä tappaa sen (niiden avainsanojen) arvon. Toki linkki toimii aina linkkinä ja on ääni toiselle sivulle, mutta on hyvä miettiä miten sen toteuttaa. Käytännössä tässä tapauksessa voimme siis unohtaa ylimmäisen linkin kokonaan.

Neljä vaihtoehtoa on vielä jäljellä, minkä pudottaisimme? Lyhyestä virsi kaunis, sanotaan… Linkeissä voidaan soveltaa periaatteessa samaa sääntöä kuin esimerkiksi sivun otsikossa, eli ensimmäiset avainsanat saavat eniten arvoa hakukoneilta.sivujen suunnittelu ja markkinointi voisi kyllä muuten jo kelvatakin, mutta haluamme saada linkistä kaiken hyödyn irti, vai mitä? Tämä siis pois.

Nyt tuleekin kinkkinen tilanne. Jäljellä on enää suunnittelu ja markkinointi, sivujen suunnittelu sekä pelkkä markkinointi. Tässä tapauksessa voidaan vielä soveltaa avainsanojen painoarvosääntöä, eli karsimme turhat pois. Vaikka suunnittelu ja markkinointi kuulostaa sinänsä houkuttelevalta, emme halua “tuhrata” painoarvoa ja -sanalle. Löytyyhän hakukoneista liki miljardi tulosta sille ja tuskin Teuvokaan tarvitsee “ja” -vierailijoita.

Jäljelle jäävät siis sivujen suunnittelu ja markkinointi. Molemmat hyviä avainsanoja Teuvolle. Järjellä ajatellen tuntuisi kuitenkin, että markkinointi olisi se jonka valitsisimme, sillä se on yksisanainen ankkuri ja saa näin enemmän painoarvoa.

Maltetaanpas kuitenkin vielä hetki ja tarkistetaan sanojen suosituimmuuus Eniron sanamittarista. Vaikka sanamittari tarkistaa vain sanojen esiintymismäärän suomalaisilla sivuilla, tarkoittaa se yleensä, että enemmän tuloksia saava on myös suositumpi hakukoneiden käyttäjien keskuudessa. Viimeistään tämä ratkaisee linkin ankkuritekstin, sillä markkinointi -sanaa esiintyy liki viisikymmenkertaisesti suomalaisilla sivuilla verrattuna sivujen suunnitteluun.

Nyt sitten ollaan siinä tilanteessa, että Teuvo on saanut hänelle tärkeällä ja oikein muotoillulla avainsanalla linkin sivuilleen. Ylläolevista esimerkeistä huomaat, että pienellä suunnittelulla voidaan saada paljon aikaan. :)

Gerg Boser huomasi muutamia päiviä sitten, että Googlen välimuistitallenne eräästä hänen bloginsa sivuista oli Google Mediapartner -robotin, eli Adsense -robotin näkemä sivu. Hän nimittäin oli luonut kokeeksi uudelleenohjaussysteemin, missä “oikea” Googlebot näkee saman minkä ihmissilmäkin ja Adsensen robotti taas riisutun version sivuista. Kokeen tarkoituksena oli selvittää kohdentuvatko Adsense -mainokset sivuille paremmin.

Nyt myös Jensense on kaivellut palvelimensa logeja. Kävi ilmi, että hänenkin sivujensa Googlen välimuistitallenteet ovat niiltä samoilta kellonlyömiltä kuin Adsense -robotti sivuilla vieraili.

Tämä asettaa uuteen valoon muun muassa sen, mitä Adsense tukisivut sanovat. Siellä nimittäin muun muassa mainitaan, että Adsensen robotin vierailut eivät ole yhteydessä Googlen indeksiin ja että Adsense -mainokset eivät ole myöskään oikotie sinne.

Vielä ei ole todisteita löytynyt siitä, vaikuttavatko Adsense -mainokset uusien sivustojen tai sivujen indeksointiin. Luulen kuitenkin, että parhaillaan kymmenet SEO:t jo testaavat tätä. Jäämme mielenkiinnolla odottamaan mahdollisia tuloksia

Muutama viikko sitten kirjoittelin hyvästä sivuston rakenteesta ja erityisesti hyvän kategorisoinnin merkityksestä navigaatiossa.

Kategoriathan sisältävät yleensä “index” -tiedoston, aivan kuten sivuston juurihakemistokin. Murtta onko kategorioiden/hakemistojen index -tiedostolla väliä?

No tiedostomuodolla tai päätteellä ei merkitystä ole, oli se sitten .html, .php tai jokin muu. Tärkeintä on se, miten linkität hakemistojen index -tiedostoihin.

Suurin virhe on linkittää sivulta A linkillä /hakemisto/index.html ja sivulta B linkillä /hakemisto/. Tällä tavalla saadaan sama sivu näkymään hakukoneille kahdella eri osoitteella = kaksi eri sivua = tuplasisältö.

On parempi pysyä vain yhdessä tavassa ja huolehtia siitä, että kaikki sivuston linkit linkittävät juuri samaan osoitteeseen. Suosittelemme käyttämään kauttamerkkiä aina, mikäli mahdollista (/hakemisto/). Vielä parempi jos voit liittää osoitteeseen automaattisesti kauttamerkin esimerkiksi Mod_Rewriten avulla tai muuten uudelleenohjata muut mahdolliset tuplasisältöä aiheuttavat osoitteet kauttaviivalla varustettuun.

Joku on varmaankin huomannut, kuinka Yahoo listaa sivustoja ja niiden kategorioita ilman kauttaviivaa. Se on kuitenkin vain silmänlumetta, sillä linkit kyllä vievät kauttaviivalla varustettuihin versioihin sivustosta/hakemistosta, mikäli sellainen vain on.

Tämä sama “hyvä tapa” pätee luonnollisesti myös domainin etusivuun. Ei siis linkitetä sinne domain.com/index.html -tiedostoon vaan suoraan osoitteeseen domain.com/

Jokainen vähänkään enemmän javascriptin kanssa kikkaillut on varmasti tutustunut <noscript> -tagin käyttöön. Useinhan tätä tagia käytetään esimerkiksi ilmoittamaan ilman javascriptia sivustolla vierailevalle, että hänen tulisi ottaa se käyttöön tai sitten luomaan linkki sivuston toiselle sivulle selaimia varten, jotka eivät tue javascriptia.

Tosiasiahan on, että hakukoneet vielä tänä päivänäkin seuraavat ja käyttävät backlinkkien laskemisessa näitä <noscript> -linkkejä, tosin niiden painoarvoa on todennäköisesti jonkin verran alennettu.

Missä menee sitten <noscript>:n käytön eettiset rajat?

Tämä kysymys heräsi mieleeni kun tutustuin erään mainostarjoajan valikoimaan jokin aika sitten. Kyseinen putiikki löytyy hakujen kärkipäästä sekä Googlessa, Yahoossa että MSN:ssä esimerkiksi hakulauseella “Pay Per Click”. Tämä ei sinänsä ole mikään ihme, sillä löytyyhän linkkejä kyseiselle sivustolle Googlesta 13500, Yahoosta 351000 ja MSN:stä 286000. Yahoon Site Explorer löytää jopa 668000 linkkiä kyseiselle sivustolle.

Millä noin suuri linkkimäärä on saatu aikaan?

Bidvertiser tarjoaa julkaisijoille Adsense -tyyppisiä mainoksia, tosin ne eivät ole konteksti- vaan sivupohjaisia. Jokaisessa mainoskoodissa mainokset tarjotaan sivustoille javascriptilla:

<!– Begin BidVertiser code –>
<SCRIPT LANGUAGE=”JavaScript1.1″ SRC=”http://bdv.bidvertiser.com/BidVertiser.dbm?pid=xxxxx&bid=xxxxx”></SCRIPT>
<noscript><a href=”http://www.bidvertiser.com”>Pay per click advertising</a></noscript>
<!– End BidVertiser code –>

Kuten huomaatte, jokaisen mainoskoodin mukana toimitetaan <noscript>:n sisään sijoitettu avainsanoilla höystetty linkki heidän sivustolleen. Toinen versio, jota on käytetty ankkurina heidän koodeissaan on affiliate program marketing. Myös tämän sanayhdistelmän eri variaatioilla on näkyvyys hakukoneissa taattu.

Mitä varten tämä noscript sitten heidän koodistaan löytyy?

Siinähän ei kovinkaan neropatti tarvitse olla arvatakseen miksi tätä tekniikkaa on käytetty. Sivustoilla vierailijoille, joilla ei javascript ole käytössä tuskin halutaan antaa “vaihtoehtoinen mainos”. Ehei, kyse on yksin ja nimenomaan linkkisuosiosta ja sitä myötä hakukonesijoituksista. Tällä tavalla käytetään myös hyväksi sinisilmäistä julkaisijaa.

Kysynkin siis vielä teiltä, missä menee <noscript>:n käytön eettiset rajat?

Missä menee hakukoneoptimoinnin eettiset rajat? Onko niitä?

Toisaalta allekirjoittaneen ei erään kisan jälkeen kannattaisia paljoa tästä suutansa aukoa, mutta haluaisinkin kuulla teidän mielipiteitänne asiasta.

Olemme käyneet läpi muun muassa sivukartan käytön sivujen indeksoinnin helpottamiseksi sekä avainsanojen käytön sivun sisäisissä linkeissä. Tässä artikkelissa käymme läpi, miten sivuston sisäinen linkitys tulisi järjestää (optimaalinen tilanne) löydettävyyden ja sivujen hakukonesijoitusten parantamiseksi.

Lähes jokaisen sivuston pääasiallisena sisääntulosivuna toimii sen juurihakemiston “index” -sivu (sivusto.com/). Oletuksena siis vierailijat ja hakukonerobotit saapuvat sivustolle miltei aina tämän sivun kautta. Siksi on luonnollista rakentaa sivuston sisäinen linkitys niin, että kaikki tärkeät sivut ovat löydettävissä mahdollisimman vähin klikkauksin. Liian syvälle sivuston uumeniin piilotetut sivut turhauttavat vierailijan sekä tuottavat myös hakukoneroboteille vaikeuksia löytää ne.

Kuten ylläolevasta esimerkistä näette, ei mikään sivuston sivu ole pidemmällä kuin kahden klikkauksen päässä käyttäjän (tai hakurobotin) sen hetkisestä sijainnista. Linkit FAQ:iin tai muille “turhille” sivuille, joilla ei ole käyttäjälle tai sivustolle juurikaan arvoa tai hyötyä kannattaa sisällyttää nofollow -tagien sisälle, sillä jokainen “ylimääräinen” indeksoitu linkki vie arvoa muilta linkeiltä. Niille ei myöskään ole välttämätöntä linkittää jokaiselta sivulta.

Kun esimerkkiin vielä lisätään linkkejä sivulta (esim. a1) sivulle (d2) ankkuroituna sille tärkeillä avainsanoilla, on varmistettu sivujen löydettävyys sekä käyttäjälle että hakukoneelle. Huomaa, että helposti löydettäville sivuille saat paljon todennäköisemmin myös ulkopuolisia linkittäjiä, kuin sellaisille, jotka ovat useamman klikkauksen takana.

Kategorisointi

Näin blogien aikakautena ylläolevan kuvan esimerkkiä käytetään aikalailla automaattisesti jokaisessa alustassa, mutta vielä on paljon perinteisellä HTML -koodauksella luotuja sivustoja, joissa navigaatio ja rakenne ovat sitä sun tätä.

Oikeanlainen kategorisointi on avainsana huolehdittaessa sivujen löytymisestä. Älä siis luo jollekin hakemistolle (kategoria) liikaa tai liian syvälle meneviä alihakemistoja, vaan pidä sivut lähellä sivuston juurihakemistoa ja luo tarvittavat uudet kategoriat sen alle.

Yksittäisen sivun sisäinen linkitys

Loppuun vielä vinkki yksittäisten sivujen sisäiseen linkitykseen:

Voit listata sisältöön tärkeitä avainsanoja, joista sivu antaa lisäinfoa ja linkittää ne seuraavalla tavalla siihen kohtaan, mistä tieto löytyy. Esimerkiksi tämän sivun yksi avainsana on kategorisointi, joka on myös heading -tagin sisällä.

Lisätään

<a name=”kategorisointi”>Kategorisointi</a>

kyseisen heading -tagin sisään ja linkitetään siihen sanalla Kategorisointi

<a href=”#kategorisointi”>Kategorisointi</a>

Tämä toimii myös linkkinä sivulle tärkeän avainsanan sisältävällä ankkurilla. Vaikka linkin osoite onkin sivuston-rakenne-linkitys.html#kategorisointi, eivät hakukoneet indeksoi risuaidan jälkeistä tekstiä osoitteessa, joten tämän pikku jipon käyttö on vaaratonta sen suhteen

Matt Cutts kirjoittteli eräästä metodista, jolla voi kieltää Googlen hakurobottia indeksoimasta sivua. Tämä siis tapahtuisi seuraavalla tavalla:

Lisää sivujesi osoitteiden perään. esim: googlebot=nocrawl

http://www.sivusto.com/artikkeli.html?googlebot=nocrawl

ja robots.txt tiedostoosi rivi:

User-agent: Googlebot
Disallow: *googlebot=nocrawl

Näin siis kiellät Googlea indeksoimasta sivuja, jotka sisältävät muuttujan googlebot=nocrawl missä tahansa osoitteen sisällä.

Tämä metodi voi olla hyödyllinen joillekin dynaamisia osoitteita käyttäville sivustoille, jotka sisältävät paljon sivuja ja joiden meta -tietoihin ei voida kirjoittaa noindex -tagia erikseen eikä osoitteita ole kannattavaa luetella yksitellen robots.txt -tiedostoon.

Matt kuitenkin jätti mainitsematta erään toisen ongelman. Nimittäin sen, että mikäli kirjoitat osoitteesi googlebot=nocrawl -muuttujan kanssa, indeksoivat myös muutkin hakukoneet (esim. MSN ja Yahoo) sivut kyseisellä tavalla (http://www.sivusto.com/artikkeli.html?googlebot=nocrawl), mikäli löytävät linkin siihen.

Tämä tapa Googlen hakurobotin poissulkemiseen sivuilta ei ole siis normaalisti suositeltavaa.

Tässä Mod_Rewrite -oppaamme jatkoksi vielä muutamia lisävinkkejä .htaccesin käyttöön:

Uudelleenohjaukset

Luonnollisesti uudelleenohjaus toimii Mod_Rewrite:n avulla:

RewriteEngine on
RewriteRule ^vanha\.html$ uusi.html [R]

Uudelleenohjauksia voidaan tehdä myös tähän tapaan ilman Rewrite engineä:

Redirect 301 /vanha-sivu.html http://www.sivusto.com/uusi-sivu.html
Redirect 302 /vanha-sivu.html http://www.sivusto.com/uusi-sivu.html

Tämän vaihtoehdon on kuitenkin oltava sallittu httpd.conf -tiedostosta. Saat sen käyttöön “AllowOverride” -kohdasta lisäämällä “All” vaihtoehdon sen perään (AllowOverride All).

Suojaa kuviasi suoralta linkitykseltä

Mod_Rewriten avulla voit helposti suojata myös sivustosi kuvia suoralta linkitykseltä toisille sivustoille. Säästät sekä kaistaa että muita palvelinresursseja, kun estät turhan liikenteen:

RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(www\.)?sivustosi.com(/)?.*$ [NC]
RewriteRule .*\.(gif|jpe?g|png|bmp|psd)$ [F,NC,L]

Jos haluat, voit myös tarjota haluamasi kuva kaistan/kuvan varastajille:

RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(www\.)?sivustosi\.com(/)?.* [NC]
RewriteRule \.(jpe?g|gif|bmp|png)$ images/kuvavaras.gif [NC,L]

Luonnollisesti voi myös lisätä useamman sivuston, jotka voivat käyttää kuviasi:

RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(www\.)?sivustosi\.com(/)?.* [NC]
RewriteCond %{HTTP_REFERER} !^http://(www\.)?toinensivustosi\.com(/)?.* [NC]
RewriteCond %{HTTP_REFERER} !^http://(www\.)?kolmassivustosi\.com(/)?.* [NC]
RewriteRule \.(jpe?g|gif|bmp|png)$ images/kuvavaras.gif [NC,L]

Kustomoidut virhesivut

Voit määritellä kustomoidut virhesivut sivustollesi helposti .htaccesin avulla. Lisäät vain esimerkin kaltaisen lauseen uudelle riville (voi toki muuttaa virhesivun numeroa mielesi mukaan) :

ErrorDocument 404 /kansio/virhe404.html

Tässä yleisimmät virhekoodit:

401 Unauthorized - pääsy kielletty (suojattu esim. salasanalla)
403 Forbidden - kielletty
404 Not Found - sivua ei löytynyt
500 Internal Error - virhe palvelimella

Kansioiden ja tiedostojen suojaaminen salasanalla

.htaccess tarjoaa yhdessä .htpasswd -tiedoston kanssa hyvän salasanasuojauksen halutuille tiedostoille tai kansioille.

Esimerkki

Halutaan kansio yksityinen suojatuksi salasanalla. oletetaan, että kansion osoite on http://www.sivusto.com/yksityinen/. Lisätään yksityinen -kansion .htaccessiin:

<files *>
AuthName “Ei pääsyä”
AuthType Basic
AuthUserFile /home/polku/salasanatiedostoon/.htpasswd
Require valid-user
</files>

Nyt luodaan .htpasswd tiedosto haluttuun paikkaan ja kirjoitetaan sen polku .htaccessin sisältöön. .htapasswd -tiedostoon ei tule liittää muuta kuin käyttäjätunnus ja salasana muodossa käyttäjätunnus:salasana. Täytyy kuitenkin muistaa, että salasana täytyy salata toimiakseen. Se onnistuu helposti esimerkiksi täällä.

Haluamme käyttäjätunnukseksi heppu ja salasanaksi hdklgs42. Syötämme ne salaajaan ja saamme tulokseksi heppu:RPnO.C0HrLEyg, jonka liitämme sis .hpasswd -tiedostoon.

Nyt jos käyttäjä yrittää pääsyä /yksityinen -kansioon, kysyy ponnahduslomake häneltä käyttäjätunnustä ja salasanaa. Jos käyttäjä ei tiedä niitä, vastaanottaa hän virhesivun.

Myös pelkästään yksittäisen tiedoston suojaaminen onnistuu muokkaamalla vain hieman edellistä .htaccessiin lisättyä koodia:

<files “tiedostonimi.html”>
AuthName “Ei pääsyä”
AuthType Basic
AuthUserFile /home/polku/salasanatiedostoon/.htpasswd
Require valid-user
</files>

(Huomaa esimerkeissämme, että blogisofta vääristää heittomerkit, joten muista muuttaa ne oikeiksi jos käytät esimerkkejä)

Mod_Rewrite on Apache -palvelimen moduuli, joka sallii osoitteiden uudelleenkirjoituksen .htaccess (Hypertext Access) -tiedoston avulla. Tässä artikkelissa käymme läpi Mod_Rewrite:n käytön dynaamisten osoitteiden muuttamisessa staattisiksi. Pyrimme näyttämään suoraan miten mikäkin tehdään jotta homma pysyy selkeänä. Jotta asia kuitenkin avautuisi mahdollisimman monelle, suosittelemme tutustumaan tähän .pdf -tiedostoon , joka sisältää muun muassa muutamia nk. Regular Expression -syntakseja, joita Mod_Rewrite käyttää.

.htaccesin suojaaminen

Ensimmäisenä tehtävänä on, tottakai, itse .htaccess -tiedoston suojaaminen ulkopuolisten katseilta. Mikäli .htaccess tiedostossasi ei ole suojausta valmiina, lisää siihen seuraavaa:

<Files .htaccess>
order allow,deny
deny from all
</Files>

Dynaamisen URL:n uudelleenkirjoitus staattiseen muotoon

Olemme saaneet yhteydenottoja lukuisilta pienyrityksiltä, jotka haluaisivat sivustoilleen parempaa hakukonenäkyvyyttä. Monilla näistä pienyrityksistä on nettikauppa, jonka tuoteryhmien/tuotteiden osoitteet on kirjoitettu dynaamiseen muotoon, esimerkiksi http://www.sivusto.com/index.php?tuote=120. Tässä on muutama huono puoli; Hakukoneet eivät vieläkään indeksoi dynaamisia sivuja niin hyvin kuin staattisia. Lisäksi sivun koko saattaa olla jopa 30% isompi verrattuna staattisilla osoitteilla varustettuun sivuun, jos se sisältää runsaasti pitkän “hännän” omaavia dynaamisia osoitteita. Täytyy myös muistaa, että staattiset osoitteet (esim. tiedosto.html) ovat myös paljon käyttäjäystävällisempiä.

Niinpä haluamme muuttaa osoitteet hakukoneystävälliseen muotoon (esim. tuote120.html). Lisäämme .htaccess tiedostoon seuraavaa (# = kommentti):

# Käynnistää Rewrite enginen. Tämä täytyy kirjoittaa aina ennen Rewrite -sääntöjä.
RewriteEngine on

# Sallii osoitteiden muokkauksen. Pakollinen, mikäli ei ole automaattisesti päällä
Options +FollowSymlinks

# Hakemisto, jota manipuloimme
RewriteBase /

# Varsinainen osoitteen uudelleenkirjoitus.
RewriteRule ^tuote([0-9]+)\.html$ /index\.php?tuote=$1 [L]

Jossa $1 (1. muuttuja) poimii tuotteen numeron. [0-9] poimii 1. muuttujan antaman luvun ja merkitsee mitä tahansa numeroa nollasta yhdeksään. + taasen merkitsee, että numeroita on yksi tai enemmän. [L] merkitsee viimeistä Rewrite sääntöä (ks. taulukko)

Jos taas tuotteen dynaaminen osoite sisältää aakkosia (esim. http://www.sivusto.com/index.php?tuote=Vehkeet), käytämme seuraavaa:

RewriteRule ^([a-zA-Z]+)\.html$ /index\.php?tuote=$1 [L]

Jossa taas [a-zA-Z] merkitsee aakkosia joko isolla tai pienellä kirjoitettuna, yksi tai enemmän jompaa kumpaa. Tuloksena saamme osoitteen Vehkeet.html.

Jos dynaaminen osoite sisältää sekä kirjaimia, että numeroita (esim. http://www.sivusto.com/index.php?tuote=aa13BE23), voimme esimerkiksi käyttää seuraavaa:

RewriteRule ^([a-zA-Z0-9]+)\.html$ /index\.php?tuote=$1 [L]

Tuloksena saamme tiedostonimen a1B2.html.

Mikäli osoitteet halutaan hakemistoiksi, voidaan .html korvata koodissa sekä / -merkillä, että jättää se kokonaan pois.

RewriteRule ^([a-zA-Z0-9]+)/$ /index\.php?tuote=$1
RewriteRule ^([a-zA-Z0-9]+)$ /index\.php?tuote=$1 [L]

Tässä on syytä muistaa, että sinun täytyy lisätä jokaiseen Rewrite -sääntöön (joka koskee hakemistojen osoitteita) kaksi vaihtoehtoa (kauttaviivalla ja ilman), tai sitten kirjoittaa sääntö, joka lisää kauttaviivan automaattisesti ja uudelleenohjaa aina kauttaviivalla varustettuun osoitteeseen:

RewriteRule ^([a-zA-Z0-9]+)$ /$1/ [R=301]
RewriteRule ^([a-zA-Z0-9]+)/$ /index\.php?tuote=$1 [L]

Jos et menettele näin, voi esimerkiksi kauttaviivalla varustettu osoite olla toimiva, kun taas ilman kauttaviivaa oleva antaa virhesivun.

Useilla muuttujilla varustetut dynaamiset osoitteet

Vaikka dynaamisessa osoitteessa olisi useita muuttujia, tehdään Mod_Rewrite samaan tapaan kuin ylläolevissa esimerkeissä.

Oletetaan, että osoite on http://www.sivusto.com/index.php?tuoteryhma=Vehkeet&tuote=23. Siispä .htaccesiin:

RewriteRule ^([a-zA-Z]+)/tuote([0-9]+)\.html$ /index\.php?tuoteryhma=$1&tuote=$2 [L]

Joka antaa tulokseksi http://www.sivusto.com/Vehkeet/tuote23.html. Muuttujia voi lisätä niin paljon kuin sielu sietää, kunhan muistaa edetä järjestyksessä ($1,$2, $3 jne.).

Myös tietyn tuotteen nimen sisällyttäminen osoitteeseen (esim. nettikauppojen käyttämissä alustoissa) on mahdollista, mutta se vaatii jo muiden tiedostojen muokkaamista, joten emme lähde tässä käsittelemään sitä asiaa sen enempää.

Luonnollisesti kun Mod_Rewrite on tehty, täytyy uudet osoitteet myös sijoittaa sivurakenteeseen. Tämä todennäköisesti vaatii sivujen osoitteiden määräävän koodinpätkän paikantamisen PHP- koodista ja sen muokkaamista. Lisäksi kannattaa tehdä uudelleenohjaus vanhoista, dynaamisista osoitteista uusiin staattisiin osoitteisiin tuplasisällön välttämiseksi.

RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /index\.php\?tuoteryhma=([a-zA-Z0-9]+)&tuote=([a-zA-Z0-9]+)
RewriteRule ^index\.php$ /%1/tuote%2\.html? [R=301,L]

Tämä siis ohjaa esim. http://www.sivusto.com/index.php?tuoteryhma=Vehkeet&tuote=23 -> http://www.sivusto.com/Vehkeet/tuote23.html kunhan muuttujina vain ovat “tuoteryhmä” ja “tuote”. Kuten tästä esimerkistä näet, voi Mod_Rewrite olla myös konditionaalista.

Hankalaa, eikö totta?

Ei oikeastaan, sillä koodi kyllä aukeaa jokaiselle, joka vähänkään viitsii tutkia sitä ja yhdistellä asioita toisiinsa. Ei kukaan ole seppä syntyessään ja testaamalla oppii. Muista kuitenkin ottaa varmuuskopiot aina ennen kuin rupeat muokkaamaan sivustosi tiedostoja.

Lisää .htaccess jippoja tulossa piakkoin..

Webmasterworldissa on käynnissä mielenkiintoinen keskustelu siitä, miten Google Pagerank -kyselyt toimivat. Keskustelussa on käynyt muun muassa ilmi se, miten PageRankin ennustustyökalut hakevat tuloksensa (mm. iwebtool.com)

Katsotaanpa, minkälaisia ennustuksia iwebtool antaa muutamille sivustoille:

Webmasterworldin käyttäjä “Hanu” kirjoitti koodin, joka mahdollistaa erilaisten XML-kyselyiden tekemisen Googleen päin. Parametreina voi käyttää muun muassa näitä:

All, Rank, Level, Filter, Hostname, URL, Results, Summary, Title, CacheSize, Link

Niinpä testasin kyseistä koodia ja hain muutamia sivustoja (www.sivusto.com) parametrina ALL. Tulokset olivat tämännäköisiä:

Tässä vielä hakukoneoptimointia.com:n XML -tiedosto, jotta saatte paremman kuvan mitä tiedostot kokonaisuudessaan sisältävät.

Monen huomio kiinnittyy varmaan RK -osioihin .XML -tiedostoissa. Ne näyttävät täsmälleen samaa kuin esim. iwebtool. Ovatko nämä sitten sivustojen tämänhetkisiä PageRank -arvoja (ei toolbarissa näkyviä) vai merkitsevätkö ne pelkästään sivuston tärkeyttä haulla www.sivusto.com tai jotain aivan muuta? Jokatapauksessa voin vain kuvitella montako uutta “PageRank prediction” -työkalua webbiin piakkoin ilmestyy ;)