Seminář: Upravujeme server - Letní škola SEO

Do úterního článku jsem nestihl vepsat několik poznámek na téma skriptovací jazyky (PHP, ASP, ASP.NET...), staticky vypadajících URL, "cool URIs" a SEO, které přikládám nyní. Kromě toho zodpovídám dotazy týkající se Mod_Rewritu.

Použití scriptovacích jazyků (PHP, ASP, ASP.NET...)

Výhodami použití scriptovacích jazyků (PHP, ASP, ASP.NET...) oproti statickým HTML stránkám se zde nebudu zabývat, protože to není obsahem článku. Místo toho se budu věnovat jejich nevýhodám oproti statickým HTML stránkám z pohledu optimalizace pro vyhledávače. Stručně řečeno: výhoda statických stránek je ta, že je vyhledávače raději indexují.

(Na druhou stranu, slyšel jsem názor, že pokud vyhledávač uvidí dynamickou koncovku, "řekne si": "Aha, tahle stránka je dynamická. S tou si dal někdo větší práci, je tedy hodnotnější. A tudíž ji posunu výše." - No, vyberte si, co chcete.)

Koncovky

Změna koncovky je tou první možností, jak může vyhledávač zjistit, že se jedná o dynamicky generovanou stránku. Je proto lepší i pro dynamicky generované stránky používat koncovky .htm a .html.

Apache i IIS dovolují asociovat jakoukoli koncovku s interprety jednotlivých scriptovacích jazyků.

Na "třetí" stranu, úplně nejlepší (rozhodně pro Jyxo) je používání cool URIs. Tedy taková URL, která jsou maximálně jednoduchá a která se nezmění, ať budete přecházet z jednoho skriptovacího jazyka na druhý (např. ASP -> PHP -> ASP.NET -> ColdFusion -> JSP, ...). Prostě aby URL, které vytvoříte dneska, mělo naprosto stejnou podobu i za dvě stě let.

Přiklad: www.example.com/novinky/takto-ma-vypadat-cool-uris/

Rychlost

I když se zpracování dynamických stránek pohybuje většinou v setinách sekund, vyhledávač pozná, že se nejedná o statické HTML stránky, kterým přikládá větší váhu než dynamickým (i když - viz poznámka výše - SEO je občas plné dohadů a velmi proměnlivé. Co platilo dnes pro vyhledávač X, nemusí platit zítra pro vyhledávač Y. Nezbývá než zkoušet).

Ještě horší ale je, že roboti neradi čekají na zpracování vašich stránek. Pokud je doba odpovědi příliš velká, bere robot stránku jako nedostupnou. Pochopte, roboti prohledávají miliardy stránek. Kdyby měli na každou čekat, byli by velmi pomalí.

V PHP skriptech největší prodlevy nastávají kvůli databázi a kódu cyklu. Vyhněte se tedy volání SELECT * a místo toho přesně pojmenujte všechny sloupce, které chcete získat.

Pokud používáte MySQL, testujte své dotazy použitím příkazu EXPLAIN.

Pro optimalizaci cyklů zvažte použití zdvojeného kódu místo cyklů, které se mnohokrát neopakují. Stejné je to s použitím statických hodnot jako count($array) uvnitř cyklu. Ty vygenerují hodnoty dříve, než cyklus skončí.

Následující dotazy jsem již zodpověděl v diskuzi, přesto je sem zkopíruji, aby byly snadno k dohledání (navíc mnoho lidí diskuze nečte).

Přesměrování

Dotaz: Potřebuji napsat přesměrování do .htaccess, které by zajistilo, že všechny soubory v adresářích adr1 a adr2:

1. jsou-li volány *.htm, server je bude vnitřně volat *.php (potud primitivní),
2. jsou-li volány *.php, server je bude vnitřně volat *.htm (vrátí str. 404),
3. jsou-li volány *.php?neco=xxx, budou se volat stejně (tedy 3. pravidlo jde proti 2. pravidlu).

Stačí, když druhou podmínku omezíte tím, že URL musí končit .php - tedy ^(.*).php$ .

Délka URL

Dotaz: Je nějak omezena doporučená délka URL pro Mod_Rewrite? Tedy zda při délce 30 znaků je adresa lépe indexována, než když má délku 130 znaků?

Pokud budete mít URL dlouhé, jednotlivá slova budou mít menší váhu, než kdybyste měli URL krátké. Z tohoto důvodů je tedy lepší používat krátká URL.

Navíc, jistě sami chápete, že čím je URL kratší, je asi důležitější. www.example.com je nepostradatelné. www.example.com/adresar bude asi nějaký důležitý adresář. www.example.com/adresar/podadresar bude nějaký podřadnější adresář, a když ze serveru odstraníte www.example.com/adresar/podadresar/nazev-clanku, asi velkou škodu neuděláte, ne? Stejně přemýšlejí vyhledávače.

Jinak se mohu pouze domnívat, že pokud je URL kratší než "magických" 256 znaků, neměl by být žádný problém s indexaci.

Zbytek bohužel nestíhám. :-(