Praėjusiame įraše privėliau filosofijos apie URL prasmę iš web skaitytojo pozicijos. Senamadiško, techniško ir well… geekiško web skaitytojo pozicijos – iš esmės tai, ko aš tikiuosi iš adresų, kuriuos “sukuria” kiti. Šiame įraše dar keletas pastabų, kurių nedera pamiršti tinklapio administratoriui.

Renkantis turinio valdymo sistemą, visada dera įvertinti tai, kad ją reikės keisti. Štai WP nėra pritaikytas PHP5 – ką jau bekalbėti apie PHP6, be to laikas nuo laiko išeina naujos jo versijos. Ir apskritai soft’as nėra amžinas – jo keitimas yra tiesiog garantuotas ilgalaikiu laikotarpiu. Tuo tarpu renkantis svetainės struktūrą reikėtų atsiminti, kad jos keitimas gali brangiai kainuoti. Renkantis adresų struktūrą visų svarbiausia įsidėmėti, kad jos keitimas užtruks ilgą laiką – tokio pragaro nelinkiu niekam.

Robotams ir vartotojams

Pirma adreso taisyklė SEO (einanti po nulinės “prikišk daug keywordų”) – jis neturėtų keistis ir idealiame pasaulyje turėtų būti amžinas. Jeigu jis pasikeitė – be abejo galima sudėlioti teisingus HTTP redirektus (301 Moved Permanently į naują adresą, vėliau laikui bėgant pakeisti į 410 Gone). Tačiau net su redirektais, adreso keitimas užsitraukia paieškos robotų nemalonę. Pavyzdys iš realybės: dar dabar kai kurie paieškos varikliai yra sucache’inę seno mano darbovietės puslapio variantą su ASP adresais ir nenori jo užmiršti. Keitimas įvyko prieš 2 metus.

Adreso pasikeitimas taipogi turi reikšmės tarp lankytojų – jų išsaugotos nuorodos pradingsta – nesvarbu ar tai buvo tiesiog browseryje, digg’e, del.ici.ous ar kaip.tikten.lt. Jeigu siekiate gero ir ilgalaikio rezultato – svetainės (ar blog’o) struktūra turėtų išlikti pastovi, net išėjus naujai PHP ar WordPress versijai, o tuo labiau pasikeitus pačiam administravimo įrankiui.

Dar viena SEO taisyklė yra “Vienas turinys – vienas adresas”. Google gana aiškiai yra išreiškusi savo poziciją apie duplicate content – ir nors dažnai jis gali atsirasti “netyčia”, į tai reikia atsižvelgti ir bent pasistengti to vengti. WordPress iki 2.3 versijos leisdavo pasiekti tą patį įrašą bent 3-4 būdais. Nors dažniausiai tos nuorodos būdavo standartinės, tai mažų mažiausiai kėlė betvarkę – fui. Net nepaisant papildomos paieškos variklių nuobaudos “neįvertinimo” pasikartojančiam turiniui, nesilaikant vieningos nuorodų struktūros prarandama dalis link juice – t.y. turinio (įrašo) reitingas padalinamas keliems adresams, o ne vienam.

Tai ko aš nepatenkintas?

WP 2.3 versija standartiškai stengiasi perkelti į canonical adresą – t.y. adresų taisyklė yra enforce’inama. Tačiau ar to pakanka? Naršant po kategorijas, archyvus, žymes ir kt. WP standartiškai rodo visą įrašo tekstą (nebent naudojama more žymė ir/arba papildomi nustatymai. Tai reiškia, kad duplicate content problema nėra išspręsta. Taipogi problematiška dalis yra puslapiavimas – įdėjus naują įrašą, viskas persislenka žemyn – tuo pačiu, tas pats turinys kuriam laikui atsiranda keliuose puslapiuose (bent laikinai – page/2, page/3). Viena bjauriausių situacijų su radinukais paieškoje būna kai ieškomas tekstas yra pvz. adrese forum.php?page=10 – tačiau kadangi virš ieškomo teksto jau žmonės yra papildomai ką nors parašę – tikrasis tekstas yra atsidūręs jau forum.php?page=12.

Paprasto sprendimo šiai problemai nėra, tačiau tiek kategorijos, tiek archyvai blog’e tėra rodyklės (turinys, index, sugalvok savo žodį) – todėl jie ir turėtų elgtis kaip tokie. Kadangi blog’as pagal savo definitioną yra chronologinis dalykas, manau, kad vienas iš mažiausiai kenksmingų variantų būtų rodyti kategorijos (tago) puslapyje kelis paskutinius įrašus, o toliau leisti browsinti pagal datą – jeigu kategorija (ar visas blogas) ganėtinai aktyvus – rodyti sakykim mėnesio įrašus, jeigu mažiau aktyvus – rodyti visus metų įrašus, taip atsikratant puslapiavimo poreikio, o tuo pačiu – niekam tikusių puslapiuotų adresų.

Adreso bei turinio pastovumas ir “patikimas” buvo dvi esminės problemos, kurios mane ilgiausiai stabdė paleidžiant savo blog’ą – norėjosi skirti pakankamai laiko apmąstymams ir šiaip dėsningumų įvertinimui tam, kad nesigailėčiau tada kai pradėsiu pasitikėti Habari. Artimiausiame įraše – mano apsisprendimas dėl struktūros.

php_value error_reporting 4095
php_flag display_errors on
php_flag display_startup_errors on