SEO kontra ASP – za URL krásnější
Ať jste či nejste pravidelnými návštěvníky Intervalu, pravděpodobně už jste slyšeli o SEO. Jedním z hlavních požadavků SEO jsou takzvané srozumitelné URL, tedy adresy složené z běžných slov, spíše než z hromádky podivných znaků. Pokud jste si jako skriptovací technologii zvolili PHP, máte velmi pravděpodobně k dispozici mod_rewrite, který vše řeší. Co ale dělat, když své stránky skriptujete v ASP?
Nejprve zvažme, proč bychom vlastně měli tvořit URL složená z běžně užívaných slov – co nám to přináší, aby nás to opravňovalo vynaložit nemalou námahu při úpravě existujícího dynamického webu nebo při tvorbě webu nového? Lidé to nejsou, ti si delší URL prakticky nikdy nepamatují. Stejně ho používají jen při práci s počítačem, který si URL může pamatovat za ně, takže z toho žádný zisk nekouká. Čitelné URL je ale jeden z dobrých nástrojů, jak dostat své stránky na přední pozice ve vyhledávačích, které nám přinášejí nové zákazníky (ať už jim říkáme jakkoli) a tedy peníze, čest a slávu.
Je jasné, že dynamický web musí mít také dynamicky generovaná URL. Tento požadavek se však s požadavkem čitelného URL dostává až příliš často do sporu. Existuje řada způsobů, kterými lze celý problém řešit a my si zde ukážeme jeden z inteligentnějších. Nicméně za vše je nutno platit, níže popsaná metoda je funkční pouze na IIS5 (MS Windows 2000 Server) a výše. Od této verze totiž lze v serveru nastavovat uživatelské chybové stránky na dynamicky generované skripty a právě od této verze obsahuje jazyk ASP také Server.Transfer, který si můžete představit jako takový Response.Redirect (přesměrování) na straně serveru, tedy bez účasti klienta. Vyhledávače totiž většinou přesměrování ignorují, aby se vyhly pasti nekonečné smyčky.
Jak to funguje
Mějme tedy server Interval.cz, na kterém publikujeme různé články. Každý článek je uložen v databázi, má své číselné ID, textové ID-ASCII, jméno a nějaký připojený text. Normálně bychom článek vyvolali přes zobrazovací skript, kterému bychom předali pomocí nějakého parametru požadované ID, například http://interval.cz/clanek.asp?article=1621. My bychom ale raději použili odkaz ve tvaru http://interval.cz/neviditelny-web-a-jine-pohadky.htm
. Taková stránka na serveru samozřejmě není, takže dojde k vyvolání chyby 404. Pro ten případ má server přednastavenu ASP stránku, kterou má předat klientovi. V této stránce ovšem číhá naše rutina, která odchytí jméno původně požadované stránky, převede je na vhodný řetězec a zkusí v databázi najít příslušný článek, který bude mít shodné ID-ASCII. Pokud takový najde, použije Server.Transfer pro získání článku z naší běžné zobrazovací stránky, pokud nikoli, předá chybovou hlášku nebo třeba provede nějakou jinou akci. A to je vše.
Jak to zařídit
Prvním krokem, kterým celou akci zahájíme, je tvorba ID-ASCII. Jak jste si v této chvíli již určitě uvědomili, nejde o nic jiného, než o název článku, převedený do malých písmen, zbavený nepotřebné diakritiky a doplněný o pomlčku všude tam, kde se původně vyskytovaly mezery nebo jakékoli nealfanumerické znaky. Tuto operaci je nejlépe zajistit v redakčním systému při vkládání článku, za pomoci nástrojů pro práci s řetězci (LCase, Replace atd.) a regulárními výrazy (RegExp, Pattern atd.). To je mimochodem další z důvodů, proč tento postup lze aplikovat pouze od IIS5 výše, potřebné funkce a metody totiž ovládá až VBS5.
Druhým krokem je konfigurace webserveru, který musíme donutit, aby k obsluze chyby 404 používal náš ASP skript, a to ještě zcela specifickým způsobem. V „Administrative Tools“ zvolte položku „Internet Services Manager“ a zde si otevřete „Properties“ inkriminovaného serveru. Na kartě „Custom Errors“ si najděte chybu 404 a pomocí „Edit Properties…“ jí nastavte cestu k příslušnému skriptu v podobě URL (jako byste ji volali coby běžnou stránku). Nezapomeňte přitom změnit „Message Type“ na „URL“. Zvlášť poslední dvě operace jsou důležité, protože pouze tehdy, bude-li server volat chybovou stránku přes protokol HTTP, předá jí v URL také název původně požadované stránky!
Třetím krokem je příprava kódu pro ASP stránku, obsluhující chybu 404. Nejprve musíme získat název původně požadované stránky a poté pomocí něj z databáze článků zjistit, jaké ID mu ve skutečnosti náleží. Myslím, že následující není třeba nijak zvlášť vysvětlovat, postačí krátké komentáře:
<%
‚ ziskame puvodni odkaz
xPageName = Request.ServerVariables(„QUERY_STRING“)
‚ definujeme hledaci funkci
Function fArticleName(patrn, strng)
Dim regEx, Match, Matches
Set regEx = New RegExp
regEx.Pattern = patrn
regEx.IgnoreCase = True
regEx.Global = True
Set Matches = regEx.Execute(strng)
fArticleName = Match(0).Value
End Function
‚ ziskame nazev clanku
xArticleName = fArticleName(„/(.*)\.html*“, xPageName)
‚ ziskame ID clanku
xSQL = „SELECT id FROM Articles WHERE ascii ='“ & xArticleName & „‚“
Set oRS = oConn.Execute(xSQL)
If (Not oRS.EOF) Then
xArticleId = oRS(„id“)
End If
‚ presmerujeme na vypis clanku
Session(„article“) = xArticleId
Server.Transfer(„/clanek.asp“)
%>
V předešlém kódu je důležitá především závěrečná sekce, kde používáme Server.Transfer("/clanek.asp")
pro přechod na stránku, která zajišťuje zobrazení článku. Pro předání ID článku musíme použít sessions a nikoli řetězec s parametrem za otazníkem jako v běžném URL, protože to IIS nedovoluje (nebo alespoň první verze, zvládající tento druh interního přesměrování). Použití Server.Transfer zajistí, že se nám vypíše výstup skriptu „clanek.asp“ aniž by došlo ke změně URL, což je přesně to, k čemu jsme celý čas směřovali.
Výhody a nevýhody
Výhoda popsaného postupu je zřejmá – získáme čitelné URL, odkazující na statické stránky, což nám otevírá cestu mezi oblíbence vyhledávačů. Nevýhoda je také zřejmá – je jí zvýšená zátěž serveru, který musí provést mnohem více operací a několik SQL dotazů navíc, a také prodloužená doba odezvy, tedy doby, uplynuvší mezi kliknutím na odkaz a zobrazením obsahu stránky. Je tedy na místě pečlivě zvážit, co je pro nás důležitější nebo co nás více omezuje.
Pokud už se rozhodnete na svém webu „zkrášlená“ URL použít, doporučuji vám považovat skript z tohoto článku pouze za vzor a upravit jej podle vlastního vkusu a potřeb. Nebylo by od věci zakomponovat do URL třeba názvy kategorií a rubrik, aby se tak zvýšila váha odkazu pro slova v něm obsažená. Nejdůležitější ze všeho je ale zabezpečení skriptu, jednak proti selhání vlivem prostého omylu či překlepu a druhak proti cíleným záškodnickým akcím.
Starší komentáře ke článku
Pokud máte zájem o starší komentáře k tomuto článku, naleznete je zde.
Mohlo by vás také zajímat
-
Jak nainstalovat šablonu ve WordPressu
23. července 2024 -
Praktické rady na zabezpečení redakčního systému WordPress
27. února 2023 -
Windows App: Pracujte odkudkoliv, kdykoliv
3. listopadu 2024 -
Souboj na trhu s CPU pro servery: AMD vs. Intel
8. prosince 2023
Nejnovější
-
Výkonný a kompaktní: ASOME Max Studio s výjimečným poměrem cena/výkon
11. listopadu 2024 -
Šokující data od Microsoftu: Kyberútoky rostou o stovky procent!
8. listopadu 2024 -
Chcete jedinečnou doménu? Objevte koncovky FOOD, MEME a MUSIC!
7. listopadu 2024 -
OpenAI představilo novou funkci ChatGPT Search
6. listopadu 2024
Anonym
Říj 21, 2010 v 21:13stránky byly vynikající a byla by škoda,kdyby ut neexstovaly