Přemístění obsahu a stavové kódy HTTP

Transkript

1 4 Přemístění obsahu a stavové kódy HTTP Jednou z výhod PHP z hlediska vývojáře webu je, že abstrahuje mnoho nízkoúrovňových implementačních detailů. V tomto směru prokazuje dokonce takovou službu, že vývojář může obvykle vytvářet složité webové aplikace, aniž by rozuměl protokolům, pomocí kterých webové servery komunikují se světem HTTP (HyperText Transport Protocol). Ačkoliv je povětšinou taková nevědomost požehnáním, v případě optimalizace pro vyhledávače tomu tak někdy není. Nesprávné použití protokolu může v hodnocení webu vyhledávači způsobit hotovou katastrofu. Na druhou stranu, pokud víte, jak protokol použít efektivně, může to být stejnou měrou užitečné. Stavové kódy HTTP jsou malé, ale rozhodující části tohoto protokolu. Poskytují informaci ohledně stavu HTTP požadavku. Dají se použít například k oznámení, že informace, na kterou požadavek směřoval, má být napříště žádána někde jinde. U moderních vyhledávačů se dá tímto způsobem také přenést hodnota odkazu na jiné umístění. Tento příklad samotný ukazuje, jak důležité je tyto kódy znát. V této kapitole vás čeká následující: Poznáte stavové kódy HTTP, které jsou důležité pro optimalizaci pro vyhledávače. Porozumíte tomu, jak správně používat stavové kódy, jak označovat odstraněné stránky a jak předejít tomu, aby vyhledávače indexovaly chybové zprávy. Naučíte se implementovat přesměrování pomocí PHP a mod_rewrite. Krok za krokem si vyzkoušíte implementaci automatické opravy URL a převádění do kanonické formy. 93

2 Kapitola 4 Přemístění obsahu a stavové kódy HTTP Stavové kódy HTTP Pokaždé, když klient (např. prohlížeč) posílá požadavek na nějakou URL na webu, server odpoví několika hlavičkami HTTP; požadovaný obsah následuje po nich. Většina uživatelů ale tuto část komunikace nikdy nespatří, protože ji většina prohlížečů běžně nezobrazuje. Pokud jste nikdy neviděli, jak takové hlavičky vypadají, je načase vás v tomto směru pokřtít. Nejjednodušší cestou je použít webový nástroj, který odvede všechnu práci za vás. Jeden takový je na adrese Na obrázku 4.1 vidíte výsledek použití tohoto nástroje s adresou Stavový kód jsme zvýraznili. Obrázek 4.1 Snazší způsob, jak si prohlédnout hlavičky HTTP, je použít rozšíření prohlížeče. Jedno z rozšíření pro Firefox je LiveHTTPHeaders ( Pro Internet Explorer můžete použít iehttpheaders ( Na obrázku 4.2 vidíte LiveHTTPHeaders v akci. Část hlaviček HTTP, která vás pro potřeby této kapitoly zajímá ze všeho nejvíce, je ta, která obsahuje stavový kód požadavku, který je vyznačený v obrázku. Nejběžnější stavový kód je 200, který znamená, že webový server požadavek úspěšně vyřídil bez jakýchkoliv nečekaných událostí a samotný obsah následuje po hlavičkách. Pro optimalizaci pro vyhledávače ovšem musíte znát i další stavové kódy. V této kapitole se budeme zabývat těmito: Přesměrování: 301 a 302 Odstraněno: 404 Chyba serveru: 500 Oficiální popis všech stavových kódů HTTP je k dispozici na rfc2616/rfc2616-sec10.html. 94

3 Přesměrování pomocí kódů 301 a 302 Obrázek 4.2 Přesměrování pomocí kódů 301 a 302 Kódy 301 a 302 jsou stavové kódy HTTP používané pro přesměrování. Oznamují, že pro splnění požadavku HTTP je nutné provést další požadavek obsah se nachází někde jinde. Když webová stránka odpoví jedním z těchto kódů, nevrací žádný obsah HTML, ale obsahuje navíc hlavičku HTTP Location:, která nese URL, kde se obsah nachází. Na obrázku 4.3 je ukázka, jak přesměrování funguje v praxi. Jak vidíte, když nastane přesměrování, URL, která přesměrovala, nevrací žádný obsah, ale určuje novou URL, na kterou má jít náhradní požadavek. Pochopitelně pokud je klientem indexovací robot vyhledávače, neúčastní se procesu žádný uživatel. Vyhledávače postupují stejným procesem, a pokud narazí na přesměrování, upravují svoji databázi. Přesměrování může být také více za sebou, tedy jedno přesměrování vede na stránku, která klienta opět přesměruje. Tuto možnost bychom ale měli nechat v teoretické rovině a vícenásobným přesměrováním bychom se měli vyhnout. Nejvyšší počet přesměrování, povolený starou verzí RFC 2616, byl pět, tento limit byl ale později zrušen. I tak je ale moudré se zřetězeným přesměrováním vyhnout, protože proces indexace zdržují roboti mohou vyřízení přesměrování pouze naplánovat, nikoliv vyřídit ihned. Doporučujeme neprovádět více než tři přesměrování. 95

4 Kapitola 4 Přemístění obsahu a stavové kódy HTTP Obrázek 4.3 Standard HTTP obsahuje více přesměrovacích stavových kódů. Jejich seznam najdete v tabulce 4.1. V praxi se ale používají pouze kódy 301 a 302. Navíc jelikož mají některé prohlížeče se zpracováním jiných stavových kódů problémy, je lepší se jim vyhnout, i kdyby se zdály pro konkrétní účel vhodnější. Můžeme také předpokládat, že s nimi neumí zacházet ani vyhledávače, nebo přinejlepším není zcela jasné, jak je interpretovat. Tabulka 4.1 Stavov kûd Popis 300 VÌce moûnostì 301 Trvale p emìstïno 302 Nalezeno 303 Viz jinde 304 NezmÏnÏno 305 Pouûij proxy 307 DoËasnÏ p esmïrov no 96

5 Kód 301 Přesměrování pomocí kódů 301 a 302 Stavový kód 301 oznamuje, že obsah je trvale přemístěný na jinou adresu určenou v hlavičce Location:, která následuje. Říká, že stará URL je zastaralá a klient by měl všechny reference na starou URL nahradit URL novou. Vezměme si jako příklad fiktivní stránku která vrací tyto hlavičky: HTTP/ Moved Permanently Date: Sun, 18 Nov :07:14 GMT Server: Apache/2.2.8 (Unix) X-Powered-By: PHP/6.0.0-dev Location: Content-Length: 0 Connection: close Content-Type: text/html;charset=utf-8 Když načtete takovou stránku v prohlížeči, automaticky se přesune na nové umístění určené hlavičkou Location. Po přesměrování vás tlačítko Zpět nepřesune na původně požadovanou stránku, jelikož tu server označil jako trvale přesunutou. Stavový kód 301 taky říká vyhledávači, že hodnotu odkazu původní URL by měl předat nové URL. Teoreticky by nová URL měla zdědit hodnocení původní URL; v praxi to ale může nějakou dobu trvat. Co se týká této věci, neměli byste URL měnit bezdůvodně. Co se týká optimalizace pro vyhledávače, stavový kód 301 je ten nejdůležitější. Nejdelší část této kapitoly věnujeme tomuto kódu a ukázkám předvádějícím jeho použití. Ale než se k těmto cvičením dostaneme, prozkoumáme v následujících částech ještě stavové kódy 302, 404 a 500. Jejich pochopení je rovněž důležité. Kód 302 Stavový kód 302 má trochu nejednoznačný význam. Oznamuje, že zdroj je dočasně přesunutý. Stará URL se nestává zastaralou a klienti nebudou výsledek ukládat do dočasné paměti, pokud jim to explicitně neřekneme hlavičkami Cache-Control nebo Expires. Aby byly věci ještě zamotanější, kód 302 používají i některé placené reklamní odkazy, ale to zde řešit nebudeme. Velký problém se stavovým kódem 302 je, že jeho význam pro vyhledávače závisí na kontextu. V praxi je účelné rozdělení na vnitřní dočasné přesměrování, tedy z jedné stránky v doméně A na jinou stránku v doméně A, a na externí dočasné přesměrování, tedy ze stránky v doméně A na stránku v doméně B. Prohlížeče se vždy při výkladu přesměrování 302 drží definice jak u interních, tak u externích. Většina vyhledávačů (včetně Google a Yahoo!) jej ale v současnosti používá pouze u interních 302. Pro interní přesměrování kódem 302 potom neukládají výsledek z přemístěné adresy a nadále ve výsledcích vyhledávání uvádějí původní doménu A. To je v souladu s definicí. Externí přesměrování 302 představují větší problém. Matt Cutts ze společnosti Google uvádí, že ve více než 99 % případů Google vypíše výsledky z nového umístění, tedy z domény B, místo těch z domény A. To je v rozporu se standardem a Google se takto chová, aby snížil riziko zvané krádež

6 Kapitola 4 Přemístění obsahu a stavové kódy HTTP Jako krádež 302 se označuje praktika, kterou se stránka na doméně A odkazuje na stránku na doméně B, která má čerstvý kvalitní obsah. Normálně by se taková stránka ohodnotila dobře na základě ukradeného čerstvého obsahu z domény B a mohla by použít metodu zahalení (cloaking) a jiné uživatele než vyhledávače přesměrovat na jiné stránky. Takové způsoby se postupně rozšířily natolik, že přiměly Google i Yahoo! změnit způsob zacházení s kódem 302, a jak prohlašuje Matt Cutts: Google přešel ke skupině heuristik, které vrací odkazovanou stránku v 99 % případů. A proč ne ve 100 % případů? Většina vyhledávačů si vyhrazuje právo na výjimky, kdy si myslí, že původní stránka bude pro hledajícího lepší, i když se to stane jen zřídkakdy. V článku na adrese Matt Cutts rozebírá externí přesměrování 302. V tomto případě není chování podle definice RFC pravidlem, ale výjimkou. Ve většině případů se s externími kódy 302 zachází jako s 301, ovšem nezpůsobí přenesení hodnoty odkazu. V praxi byste měli zvážit, jestli vůbec přesměrování 302 potřebujete. Pokud dočasně potřebujete na URL poskytovat jiný obsah než obvykle, je lepší změnit obsah průhledně. Možné způsoby implementace jsou pomocí include() nebo pomocí načtení a zobrazení alternativního obsahu ze vzdáleného umístění, čímž se vyhnete nutnosti použít přesměrování 302; toho dosáhnete pomocí funkcí PHP curl Client URL Library. Pokud se tedy stará stránka jmenuje stara_stranka.php a stránka s novým obsahem se jmenuje nova_stranka.php, potom můžete jednoduše vložit obsah z nové stránky: include('nova_stranka.php'); Pro načtení obsahu z jiného serveru pomocí URL stačí provést něco podobného: $ch = curl_init(); curl_setopt($ch, CURLOPT_URL, ' curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1); echo curl_exec($ch); Odstranění stránek pomocí 404 Každý s širokými prsty někdy viděl stavový kód 404. Znamená, že URL, kterou klient požaduje, neexistuje. Některé technické detaily ohledně tohoto kódu ovšem tak zřejmé nejsou. Zaprvé není zcela známo, že se stavovým kódem 404 může server odeslat také obsah stejně jako se stavovým kódem 200. Je pravda, že lidé si obvykle spojují kód 404 s obecnou chybovou stránkou serveru Apache; nemusí to tak ale být vždy. Některé weby upravují stránky 404 tak, aby uživatelům pomohly. Lepší weby mohou dokonce na základě klíčových slov v požadované URL uživateli navrhnout, co mohli hledat. Ať už je ale stránka 404 obecná nebo upravená, vždy říká vyhledávačům, že stránka neexistuje; a pokud ano, měli by ji odstranit ze své databáze. Vyhledávače nikdy neindexují stránku, kterou obdrží s kódem

7 Zabránění indexování chybových stran pomocí kódu 500 U statických stránek je zobrazení chyby 404 automatické jednoduše smažte soubor. Bohužel spoustu dynamických webů koncept kódu 404 ignoruje, protože to představuje trochu úsilí na implementaci navíc. Obvykle když produkt vymažete z databáze, na ostatních stránkách webu se už na něj nevyskytují žádné odkazy. Na stránku produktu ale stále mohou odkazovat externí weby, tím pádem mají jistou nabytou hodnotou odkazu a zůstávají v databázích vyhledávačů. Nejhorší, co můžete udělat, je vrátit prázdnou stránku se stavovým kódem 200 jak se často stává u produktů, které již nejsou v databázi. To vede k mnoha prázdným stránkám, které vyhledávač zaindexuje, čímž vzniká duplicitní obsah. Místo toho byste měli vrátit kód 404, případně i s chybovou zprávou. Častou chybou je, že web zobrazí zprávu stránka nebyla nalezena, ovšem se stavovým kódem 200. Hostingové služby většinou umožňují nastavení vlastní stránky 404 tedy stránky, která se má zobrazit, pokud klient požádá o URL, která neexistuje. Nemusí ale správně nastavit stavový kód 404, což může vést k teoreticky nekonečnému množství stejných stránek na vašem webu. Jestli tedy web vrací správný kód, se můžete přesvědčit pomocí nástrojů uvedených výše v této kapitole. A jaké z naší pohádky plyne ponaučení? Dodržujte štábní kulturu. Pro všechen odstraněný obsah vracejte stavový kód 404. Někteří zkušení optimalizátoři navrhují místo kódů 404 vracet stránku se souvisejícími produkty. To zachová hodnotu odkazů, zatímco při použití 404 o ni přijdete. Zařídit to můžete v souboru.htaccess nebo v PHP pomocí přesměrování 301, řešení předvedeme později v této kapitole. Zabránění indexování chybových stran pomocí kódu 500 Za devatero routery a sedmero firewally, v zapomenuté serverovně, běžel jeden server, tu a tam vyřídil požadavek, a žil šťastně až do až do chvíle, kdy spadla databáze. Jelikož to je nepředpokládaný stav (všichni bychom mohli zapracovat na lepším ošetření chyb!), spoustu stránek začalo vracet prázdné stránky s chybovými zprávami nebo kódy 404. Možná se sesypal i samotný server. A aby to bylo ještě horší, nemáte momentálně nic, čím ho nahradit. Mezitím se vyhledávač rozhodne vaše stránky zas po čase navštívit a zaindexovat; a co nenajde: prázdné stránky, chybové hlášky a podobné smetí. Zde jsou možnosti: Váš web vrací 404 nebo prázdné stránky. To je opravdu vážná nepěkná věc. Pokud server vrací 404, vyhledávač vaše stránky odstraní z databáze. Pokud vyhledávač vidí prázdné stránky nebo stránky nadívané chybovými zprávami a varováními, může udělat to samé. Tomu byste se měli pokusit za každou cenu vyhnout. Nenalezne nic (nelze se se serverem spojit). To je, co se indexování vyhledávači týká, překvapivě lepší situace než předchozí. Jakkoliv se to může jevit hodně neprofesionálním, vyhledávač může předpokládat, že nastaly problémy s konektivitou, a zkusí indexovat později. Vaše uživatele to ovšem může naštvat. Z pohledu indexovacího robota to ale není takový problém, pokud dojde v krátké době k nápravě. 99

8 Kapitola 4 Přemístění obsahu a stavové kódy HTTP Takže jaké je správné řešení? Je to vlastně úplně jednoduché. Server může vrátit stavový kód 500 doprovázený stránkou, která popisuje chybu. Tak dá najevo vyhledávačům, že má dočasné potíže, nebo možná je server odstavený kvůli údržbě. Slušně to oznámí a poskytne čas, kdy bude opět v provozu. Nebo se možná udála živelná pohroma jako v případě tisícileté vody v Čechách v roce Pro všechny URL je tedy nutné nastavit chybovou stránku se zprávou o situaci, dokud se věci neurovnají. Pokud tedy chcete něco takového provést v PHP, použijte podobný kód: header("http/ Vnitřní chyba serveru"); echo "Banka je zavřená, dokud Marťané nevystoupí z koalice a neodletí ". "zpátky na Mars. Omlouváme se za nepříjemnosti a děkujeme za pochopení."; exit(); Přesměrování pomocí PHP a mod_rewrite Odteď dále tato kapitola popisuje zejména použití stavového kódu 301. Můžete jej implementovat buď pomocí PHP, nebo mod_rewrite. Při použití mod_rewrite je postup podobný jako u přepisování URL, jenom přidáte stavový kód přesměrování jako příznak. Následující pravidlo provede přesměrování 301 na bar.php při požadavku na foo.php. RewriteRule ^foo\.php$ /bar.php [R=301,L] Kromě nového příznaku R na konci pravidla zde pro vás není nic nového ale ten příznak představuje významný rozdíl. Ať už tam příznak R je nebo není, návštěvník by nakonec viděl obsah na stránce bar.php. Když ale použijete přesměrování, návštěvníkův prohlížeč provede dva požadavky na server. Prvním požádá o foo.php; v odpovědi se mu dostane přesměrování stavovým kódem 301 v hlavičce HTTP s určením nového umístění bar.php. Následně klient požádá o bar.php a dá uživateli vědět, že se dostal na jinou URL, tím, že změní URL v adresním řádku. V PHP můžete přesměrovat přidáním hlavičky HTTP prostřednictvím funkce header(). Pokud chcete, aby foo.php poslala klienta na bar.php kódem 301, skript foo.php by měl vypadat takto: <?php header('http/ Trvale přemístěno'); header('location: Pokud se objeví pouze hlavička Location bez explicitního uvedení stavového kódu, předpokládá se automaticky kód 302 dočasné přesměrování. Pamatujte na to. V praxi pokud úpravy webu vyžadují změny v URL, správce webu by měl přesměrovat aspoň nejdůležitější URL na jejich nové protějšky. Jinak web přijde o nabytou hodnotu odkazů. Použití přesměrování 301 problém zmírní. Pokud už je váš web zaindexovaný, musíte nechat systematicky přepisovat staré URL na nové. 100

9 Přesměrování pomocí PHP a mod_rewrite Použití přesměrování při změně názvu souboru Ve cvičení, které následuje, upravíme stránky produktu, které jsme vytvořili v kapitole 3, tak, aby přesměrovávaly všechny dynamické URL na verze s klíčovými slovy. Momentálně můžeme ke stejnému obsahu přistupovat jak přes dynamické URL, tak přes URL s klíčovými slovy (viz obrázky 3.9 a 3.12 v kapitole 3); následující dva odkazy tedy vedou na stejný obsah: a Abyste předešli jakýmkoliv problémům plynoucím z toho, že dvě různé adresy vedou na stejný obsah, zajistěte, aby stránka dosažená jinou URL vždy klienta přesměrovala na tu správnou s klíčovými slovy. To je zásadní při přechodu na statické URL u existujícího webu, protože staré URL už určitě vyhledávače v databázích mají. Dobrá, jsme si jisti, že dychtíte po dalším kódu! Vyzkoušejte Přesměrování dynamických URL na URL s klíčovými slovy 1. Následující kód přidejte do souboru config.inc.php. Tato globální asociativní pole definují řadu produktů a kategorií a simulují opravdovou databázi produktů. Data v nich obsažená budete potřebovat k vygenerování URL s klíčovými slovy pomocí PHP. Pole používáme místo skutečné databáze pro zjednodušení příkladu. <?php // Doména webu; bez '/' na konci! define('domena_webu', ' // Vytvoříme fiktivní databázi produktů a kategorií $GLOBALS['produkty'] = array ("45" => "Rovnač na ohybač", "31" => "Stěrače na ponorku", "42" => "Bublinka do vodováhy"); $GLOBALS['kategorie'] = array ("12" => "Kutilské potřeby", "6" => "Auto-Moto", "2" => "Stavebnictví");?> 2. Vytvořte soubor include/presmerovaniurl.inc.php a do něj vložte tento kód: <?php // Načteme knihovnu továrny na URL require_once 'include/urltovarna.inc.php'; 101

10 Kapitola 4 Přemístění obsahu a stavové kódy HTTP // Přesměruje na správnou URL, pokud už na ní není. function OpravURLKategorieAProduktu() { // Získáme správnou URL pro aktuální stránku kategorie/produktu. $spravnaurl = ZískejURLKategorieAProduktu(); } // Přesměrujeme pomocí 301 na správnou URL, pokud je to nutné. if( DOMENA_WEBU. $_SERVER['REQUEST_URI']!= $spravnaurl ) { header('http/ Trvale přemístěno'); header('location: '. $spravnaurl); exit(); } // Vrací správnou URL s klíčovými slovy function ZískejURLKategorieAProduktu() { // Získáme ID produktu a kategorie z dotazové části URL. $iidproduktu = $_GET['id_produktu']; $iidkategorie = $_GET['id_kategorie']; // Z fiktivní databáze získáme jména kategorie a produktu. $snazevproduktu = $GLOBALS['produkty'][$iIdProduktu]; $snazevkategorie = $GLOBALS['kategorie'][$iIdKategorie]; // Vytvoříme URL s klíčovými slovy. $spravnaurl = VytvorURLProduktuAKategorie( $snazevkategorie, $iidkategorie, $snazevproduktu, $iidproduktu ); // Vytvořenou URL s klíčovými slovy vrátíme. return $spravnaurl; }?> 3. Do souboru produkt.php vložte tyto řádky: <?php // Načteme knihovnu s funkcemi na přesměrování. require_once 'include/presmerovaniurl.inc.php'; // Přesměrujeme klienta na správnou URL, pokud už na ní není. OpravURLKategorieAProduktu(); 102

11 Přesměrování pomocí PHP a mod_rewrite // Zobrazíme detaily produktu. echo 'Vybral(a) jste produkt č. '. $_GET['id_produktu']. ' z kategorie č. '. $_GET['id_kategorie'];?> 4. V prohlížeči načtěte adresu a sledujte, co se stane zajímavého s URL v adresním řádku! Na obrázku vidíte, jak server požadavek přesměroval na příslušnou správnou verzi URL s klíčovými slovy. Obrázek 4.4 Nejprve upravujeme produkt.php, aby se načetla knihovna PresmerovaniURL.php, a potom zavoláme v ní obsaženou funkci OpravURLKategorieAProduktu(): <?php // Načteme knihovnu s funkcemi na přesměrování. require_once 'include/presmerovaniurl.inc.php'; // Přesměrujeme klienta na správnou URL, pokud už na ní není. OpravURLKategorieAProduktu(); Funkce OpravURLKategorieAProduktu(), kterou voláme při každém načtení stránky produktu, kontroluje, jestli URL, přes kterou se klient ke stránce dostal, je ta správná. Správnou verzi vytvoříme pomocnou funkcí ZískejURLKategorieAProduktu(): // Přesměruje na správnou URL, pokud už na ní není. function OpravURLKategorieAProduktu() { // Získáme správnou URL pro aktuální stránku kategorie/produktu. $spravnaurl = ZískejURLKategorieAProduktu(); Jak pracuje funkce ZískejURLKategorieAProduktu(), vysvětlíme za okamžik. Prozatím budeme předpokládat, že proměnná $spravnaurl obsahuje něco jako Jakmile získáme správnou URL, ověříme, zda URL, přes kterou se návštěvník dostal na stránku produktu, je stejná: // Přesměrujeme pomocí 301 na správnou URL, pokud je to nutné. if( DOMENA_WEBU. $_SERVER['REQUEST_URI']!= $spravnaurl ){ Hodnota $_SERVER['REQUEST_URI'] obsahuje URL bez doménového jména, na kterou směřoval požadavek. Například pokud směřoval na 103

12 Kapitola 4 Přemístění obsahu a stavové kódy HTTP id_produktu=41, $_SERVER['REQUEST_URI'], obsahuje /produkt.php?id_kategorie=2&id_produktu=41. Připojením doménového jména k této hodnotě získáme celou URL. Pokud se správná a použitá URL neshodují, provedeme přesměrování 301 na správnou stránku. To provedeme nastavením správných hodnot hlaviček HTTP: // Přesměrujeme pomocí 301 na správnou URL, pokud je to nutné. if( DOMENA_WEBU. $_SERVER['REQUEST_URI']!= $spravnaurl ) { header('http/ Trvale přemístěno'); header('location: '. $spravnaurl); exit(); } Teď se podíváme na funkci ZískejURLKategorieAProduktu(). Ta začíná získáním identifikátorů produktu a kategorie, které jsou obsaženy v URL, z proměnné $_GET: // Vrací správnou URL s klíčovými slovy function ZískejURLKategorieAProduktu() { // Získáme ID produktu a kategorie z dotazové části URL. $iidproduktu = $_GET['product_id']; $iidkategorie = $_GET['category_id']; Potom načteme jména produktu a kategorie z naší fiktivní databáze: // Z fiktivní databáze získáme jména kategorie a produktu. $snazevproduktu = $GLOBALS['produkty'][$iIdProduktu]; $snazevkategorie = $GLOBALS['kategorie'][$iIdKategorie]; Fiktivní databáze se skládá ze dvou globálních asociativních polí, která spojuje identifikátory se jmény. Definujeme je v souboru config.inc.php. Pole simulují opravdovou databázi produktů. Používáme je místo databáze, abychom příklad co nejvíce zjednodušili. Pokud byste ale vytvářeli skutečnou aplikaci, použili byste normální databázi. // Vytvoříme fiktivní databázi produktů a kategorií $GLOBALS['produkty'] = array ("45" => "Rovnač na ohybač", "31" => "Stěrače na ponorku", "42" => "Bublinka do vodováhy"); $GLOBALS['kategorie'] = array ("12" => "Kutilské potřeby", "6" => "Auto-Moto", "2" => "Stavebnictví"); Když máme tato data k dispozici, můžeme pokračovat ve funkci ZískejURLKategorieAproduktu(). Pomocí funkce VytvorURLProduktuAKategorie() z továrny na URL vytvoříme URL s klíčovými slovy: 104

13 Přesměrování pomocí PHP a mod_rewrite // Vytvoříme URL s klíčovými slovy. $spravnaurl = VytvorURLProduktuAKategorie( $snazevkategorie, $iidkategorie, $snazevproduktu, $iidproduktu ); Nakonec vrátíme výslednou hodnotu: // Vytvořenou URL s klíčovými slovy vrátíme. return $spravnaurl; Oprava URL Největší výhoda současné podoby přepisování URL s klíčovými slovy je, že se při hledání dat produktů a kategorií nespoléháte jen na jejich jména, ale na jejich identifikátory, které šetrně vkládáme do URL. Funguje to perfektně, protože text v URL se může změnit, aniž bychom potřebovali cokoliv přeprogramovat. U takto fungujících odkazů ale existuje jedno riziko. Když se změní název produktu nebo kategorie, znění URL se automaticky změní také. Jak už víte, to může vést k výskytu duplicitního obsahu, a to určitě nechcete! V aktuální podobě našeho cvičného webu existuje nekonečný počet různých URL, které vedou na stejný obsah. Vezměme si například tyto dvě různé URL: a Vylepsena-bublinka-do-vodovahy-s-vitaminem-C-P42.html Řešení, které navrhujeme, spočívá v přesměrování na jedinou standardní verzi URL. Naštěstí pro vás již tuto funkci máme implementovanou! Funkce OpravURLKategorieAProduktu() ze skriptu PresmerovaniURL.inc.php se již v případě, že URL nemá podobu, jakou mít má, postará o přesměrování jakékoliv pochybené či zastaralé verze na správnou. Zkuste v prohlížeči načíst druhou z výše uvedených URL a server by vás měl navést správnou URL: Správné zacházení s více doménovými jmény Ačkoliv už to dnes tak populární není, někteří lidé touží mít více domén, které směřují na stejný web. Kupříkladu řekněme, že máte tato tři doménová jména:

14 Kapitola 4 Přemístění obsahu a stavové kódy HTTP Problém je, zvlášť pokud vedete kampaň na všechna tři doménová jména, že lidé mohou odkazovat na váš web kteroukoliv z těchto domén. Tak vzniká ohromný problém s duplicitou obsahu. Musíte vybrat standardní doménu a vytvořit trvalé přesměrování z ostatních domén na vybranou. Vyberme si třeba Přesměrování provedeme pomocí mod_rewrite takto: RewriteEngine on RewriteCond %{HTTP_HOST}!^www\.example\.com RewriteRule ^(.*)$ [R=301,L] Hotovo! Odteď server vše přesměruje na Pravidla si probereme detailně. Poprvé používáme direktivu RewriteCond. Ta se používá k nastavení podmínky pro pravidlo, které následuje. V tomto případě chceme zajistit, že se pravidlo aplikuje, pouze pokud požadavek směřuje na jinou doménu než Podívejme se na řádku s RewriteCond: RewriteCond %{HTTP_HOST}!^www\.example\.com Řádka určuje podmínku, která je splněna, pokud doménové jméno hostitelského serveru (HTTP_HOST) není (!) Přepisovací pravidlo RewriteRule potom uloží celý řetězec dotazu výrazem (.*) a předá ho na doménu kam požadavek přesměruje. Takto se například požadavek na přesměruje kódem 301 na Použití přesměrování ke změně doménového jména Někdy se stane, že potřebujete změnit doménové jméno. To může být například případ sloučení a začlenění jedné společnosti do druhé. Změna domény je sice nevítaná, ale nutná. Dá se provést správným způsobem, ale také mnoha špatnými. Obvykle je po sloučení nutné obě staré domény směřovat na stejný web. Nejhorší, co můžete udělat, je směrovat obě doménová jména na stejný obsah pomocí DNS. Tak se stane, že vyhledávače nevědí, které z nich je hlavní. V průběhu let pravděpodobně vznikly spousty odkazů na obě doménová jména a vyhledávače budou nejspíše mít velké problémy s rozhodováním, kterou verzi zaindexovat. Výsledkem je velký problém s duplicitním obsahem. Také byste mohli jednu z domén vyřadit z provozu nebo na ni dát oznámení pro uživatele, že mají používat novou doménu. Obě tyto metody předejdou penalizaci za duplicitní obsah, ale neprovede se předání hodnoty odkazů. Správná cesta, jak takový přechod uskutečnit, je pomocí přesměrování 301 na novou doménu. Jednoduše dejte do souboru.htaccess tyto direktivy: RewriteEngine on RewriteCond %{HTTP_HOST} ^old\.example\.com [OR] RewriteCond %{HTTP_HOST} ^www\.old\.example\.com RewriteRule ^(.*)$ [R=301,L] To modulu mod_rewrite přikazuje, aby požadavky na staré domény old.example.com nebo trvale přesměroval na při zachování všech parametrů dotazového řetězce. Pravidlo RewriteRule se vykoná jen tehdy, když požadavek splní jednu z podmínek RewriteCond. 106

15 Převod URL do kanonické formy: versus example.com Také byste mohli použít pravidla s podobným významem: RewriteEngine on RewriteCond %{HTTP_HOST}!^www\.new.example\.com RewriteRule ^(.*)$ [R=301,L] Ta přikazují modulu mod_rewrite, podobně jako při kanonikalizaci, že všechny požadavky na správnou doménu má přesměrovat. Převod URL do kanonické formy: versus example.com Další téma, které se objevuje stále dokola. Jelikož všechny vyhledávače (včetně Google, dokonce i po nové verzi BigDaddy) mají problémy, když je web přístupný jak na doméně tak na example.com, měl by zodpovědný správce webu tuto nejednoznačnost odstranit. Jinak mohou vyhledávače zaindexovat obě verze a vzniká problém duplicitního obsahu. Náprava je úplně jednoduchá. Prostě vložte do souboru.htaccess tyto direktivy: RewriteCond %{HTTP_HOST} ^example\.com RewriteRule ^(.*)$ [R=301,L] Říkají, že každý požadavek na example.com[cesta] se má trvale přesměrovat na Případně můžete místo toho použít něco s podobným výsledkem: RewriteEngine on RewriteCond %{HTTP_HOST}!^www\.example\.com RewriteRule ^(.*)$ [R=301,L] To říká, že jakýkoliv požadavek na tento web, který přichází přes jiné doménové jméno než má mod_rewrite přesměrovat právě na něj. Taková definice má ale širší záběr a nemusí to být přesně to, co máte v úmyslu. Přesměruje také jakékoliv jiné domény, které vedou na váš web, na Poznámka: Vůbec není dobrý nápad použít nástroj na odstranění webu k odstranění stránek example.com, dokonce i poté, co jste provedli tyto změny! Může to vést k úplnému odstranění webu. Matt Cutts ze společnosti Google říká: Pokud odstraníte některou verzi doménového jména (s www nebo bez), Google může celou vaši doménu na šest měsíců odstranit. Proto to v žádném případě nedělejte. ( Místo toho nežádoucí domény přesměrujte kódem 301 na tu správnou a problém by se měl po čase vytratit. Kanonikalizace URL: /index.php oproti / Koncept výchozích stránek bohužel způsobuje další problém s duplicitním obsahem. Pokud požadavek neuvádí žádný soubor nebo adresář, server obvykle vrátí výchozí stránku, ale bez přesměrování. Problém se potom vyskytne, když na stránku existují odkazy s oběma verzemi ať už z webu samotného nebo z externích webů. To vede k problému s duplicitním obsahem, protože 107

16 Kapitola 4 Přemístění obsahu a stavové kódy HTTP existují dvě URL, které vedou na stejný obsah. Ani jedna z verzí URL není ta správnější, ačkoliv lepší jsou kratší URL, proto preferujeme spíše / než /index.php. Řešení je podobné jako u problému oproti example.com. Musíte nastavit přesměrování kódem 301 na příslušný adresář, kdykoliv server obdrží požadavek na cestu končící index.php nebo index.html. Kód přesměrování se dá jednoduše implementovat pomocí pravidel mod_rewrite nebo v PHP. Pomocí mod_rewrite to provedete přidáním následujících řádek do souboru.htaccess: RewriteCond %{THE_REQUEST} ^GET\.*/index\.(php html)\ HTTP RewriteRule ^(.*)index\.(php html)$ /$1 [R=301,L] Po povedení této změny zkuste načíst adresu a server by vás měl přesměrovat na Případně pokud chcete stejného efektu docílit v PHP, v následujícím cvičení se dozvíte, jak. Vyzkoušejte Přesměrování index.php 1. V adresáři seophp vytvořte soubor s názvem index.php s následujícím kódem: <?php // Přesměruje aktuální požadavek, pokud je třeba. require_once 'include/presmerovaniurl.inc.php'; // Přesměruje požadavky na index.php nebo index.html na obsahující adresář. OpravIndexURL();?> <!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.1//EN > <html> <head> <meta http-equiv="content-type" content="text/html; charset=windows-1250"/> <title>seo Egghead: SEO pro zelenáče</title> </head> <body> <h1>vítejte na SEO Egghead!</h1> </body> </html> 2. Do souboru PresmerovaniURL.inc.php přidejte tento kód: <?php // Načteme knihovnu továrny na URL require_once 'include/urltovarna.inc.php'; // Přesměruje požadavky na index.php nebo index.html na obsahující adresář. function OpravIndexURL() { 108

17 Převod URL do kanonické formy: versus example.com // Pokud je požadavek na index.php nebo index.html, // přesměrujeme na obsahující adresář. if( preg_match('#(.*)index\.(html php)$#', $_SERVER['REQUEST_URI'], $promenne) ) { // Provedeme přesměrování 301 na novou URL. header('http/ Trvale přemístěno'); header('location: '. DOMENA_WEBU. $promenne[1]); } }...?> 3. Načtěte a server by vás měl přesměrovat na (viz obrázek 4.5). Obrázek 4.5 Kód je celkem jasný. Napřed jsme vytvořili velmi jednoduchou stránku index.php, která obsahuje jen titulek. Zvláštní na ní je ale to, že na začátku načítá skript PresmerovaniURL.inc.php. Ten zkontroluje, jestli požadavek na stránku přistupuje přes jednu ze stránek index.php nebo index.html: // Pokud je požadavek na index.php nebo index.html, // přesměrujeme na obsahující adresář. if( preg_match('#(.*)index\.(html php)$#', $_SERVER['REQUEST_URI'], $promenne) ) Zde používáme regulární výrazy ke kontrole, zda URL končí výše zmíněnými názvy souborů. Voláme funkci preg_match() a uzavřením výrazu.* do závorek (.*) žádáme o uložení všech znaků předcházejících názvu souboru do třetího parametru $promenne. Tyto znaky potom budou URL, na kterou chceme požadavek přesměrovat. Pokud tedy URL vyhovuje, provedeme přesměrování 301: if( preg_match('#(.*)index\.(html php)$#', $_SERVER['REQUEST_URI'], $promenne) ){ // Provedeme přesměrování 301 na novou URL. header('http/ Trvale přemístěno'); header('location: '. $promenne[1]); } 109

18 Kapitola 4 Přemístění obsahu a stavové kódy HTTP Další typy přesměrování Existují ještě další typy přesměrování, například pomocí elementu meta refresh a javascriptová přesměrování, jejich používání ale nedoporučujeme. V minulosti je často zneužívali spameři a z toho důvodu je jejich použití téměř vždy podezřelé. Když už použijete meta refresh, nenastavujte prodlevu menší než 10 sekund. Obvyklé použití meta refresh vypadá takto: <!-- Přesměruj na SEO Egghead za 10 seconds --> <meta http-equiv="refresh" content="10;url= Přesměrování založené na JavaScriptu vůbec nedoporučujeme používat. Pokud na něj vyhledávač přijde, velmi pravděpodobně udělí nějakou penalizaci. Shrnutí V této kapitole jsme předvedli, že základní porozumění důležitým stavovým kódům HTTP je pro správnou optimalizaci pro vyhledávače velice podstatné. Obchodní rozhodnutí si někdy vyžádá změnu stránky, domény nebo odstranění obsahu. Tím, že dáte vyhledávači o těchto změnách vědět, předejdete nepříjemným nedorozuměním. 110