it-swarm-eu.dev

Mám použít příponu souboru nebo ne?

Vždy jsem o tom přemýšlel a nikdy jsem nenašel dobré řešení.

Ale tato otázka mi to připomnělo.

Když na svém webu mám adresu URL, lze ji zobrazit a získat přístup k některému z následujících způsobů:

http://www.somesite.com/subdirectory
http://www.somesite.com/subdirectory/
http://www.somesite.com/subdirectory/index.htm
http://www.somesite.com/subdirectory/index.html
http://www.somesite.com/subdirectory/index.php
http://www.somesite.com/subdirectory/index.asp
http://www.somesite.com/subdirectory/some-relevant-keywords
http://www.somesite.com/subdirectory/some-relevant-keywords.htm
http://www.somesite.com/subdirectory/index.php?page=some-relevant-keywords
http://www.somesite.com/subdirectory/?page=some-relevant-keywords
http://www.somesite.com/subdirectory/?page=some-relevant-keywords&even=more-keywords

atd...

Nyní chápu výhody přidání klíčových slov do adresy URL. Dokonce i ten nejzákladnější průvodce SEO se zmíní. ... ale kvůli rozumu, srozumitelnosti, snadnému čtení, snadnému použití atd. , včetně souladu s webem ...

Je preferováno mít příponu souboru nebo ne?

Opravdu, hluboko v mé logice mi říká: ano, mělo by. Důvodem je to, že pramení z dob minulosti, kdy byl internet většinou USENET, FIDONET, FTP a Gopher.

Podívejte se, pokud URL nemá název souboru , pak se obvykle považuje za adresář . Zde vznikl index.htm, protože ve výchozím nastavení je uveden adresář, pokud není nalezen žádný indexový soubor. Weboví programátoři to však začali brzy přepisovat a pomocí index.htm skutečně sloužili obsahu webového adresáře jako stránky . Hlavní rozdíl byl v tom, že byl přidán značkovací jazyk, který byl v prohlížeči analyzován. S tímto značkovacím jazykem se značka Content-Type:text/html; v záhlaví odpovědi stala indikátorem toho, jaký byl typ souboru pro jakýkoli soubor . HTML se jeví jako jediný „typ souboru“, který prostě nemá důsledně pojmenovaná rozšíření, s výjimkou případů, kdy jsou uložena.

Bohužel, jakmile se webové stránky staly hlavní věcí, stalo se bezpečnostní chybou, aby se skutečně zobrazil obsah adresáře, takže vše zůstalo skryté a zobrazoval se pouze skutečný obsah URL.

Nemluvě o válkách pro pojmenování souborů napříč platformami .. Windows vyžadují 3 nebo méně číslicové rozšíření a unix/mac může mít více. Mělo by to tedy být .HTM nebo .HTML nebo NONE a nechat platformu rozhodnout?

Takže se v podstatě domnívám, že to, co se snažím zjistit, je nad rámec SEO a zabývám se více estetikou a dodržováním webu.

26
Talvi Watia

Rozšíření použijte, pokud existuje více než jedno zastoupení nebo kde je klientský software absolutně hloupý, a odmítá přijmout pouze typ obsahu (QuickTime, RealPlayer, Outlook atd. Dívám se na vás):

  • http://www.somesite.com/subdirectory - může to být vaše verze s automatickým vyjednáváním, která používá značky Canonical META k označení skutečné reprezentace

  • http://www.somesite.com/subdirectory/ - vždy stojí za to podporovat koncové lomítka na libovolné adrese URL, ale pomocí značek Canonical META (nikoli přesměrování, protože se jedná o zbytečné zpomalení), aby odkazoval na správnou adresu URL

  • http://www.somesite.com/subdirectory/index.htm a http://www.somesite.com/subdirectory/some-relevant-keywords.htm - limit rozšíření o tři znaky se nevztahuje na HTTP (pouze základní FileSystem/OS), takže si ho může klient uložit jako index.html nebo aa, pokud chtěl, zatímco ještě mít k němu přístup

  • http://www.somesite.com/subdirectory/index.html - pokud obsluhujete verzi .atom, .xml nebo podobnou verzi, pak má smysl ctít i verzi .html (a Canonically na ni odkazovat prostřednictvím značek LINK v dohodnuté verzi) - použijte obsah HTTP - Přestože záhlaví umístění odkazuje na verzi automatického vyjednávání - pamatujte, že můžete také použít vícejazyčné (.en, .es, atd ...) nebo multi-charset (.utf8, .utf16, atd ...)

  • http://www.somesite.com/subdirectory/index.php a http://www.somesite.com/subdirectory/index.asp - pokud nesloužíte zdrojovému kódu, pak tyto nemají smysl podporovat

  • http://www.somesite.com/subdirectory/some-relevant-keywords - SEO je neustále se měnící umění a pokud to funguje pro vás, pak skvělé

  • http://www.somesite.com/subdirectory/index.php?page=some-relevant-keywords, http://www.somesite.com/subdirectory/?page=some-relevant-keywords a http://www.somesite.com/subdirectory/?page=some-relevant-keywords&even=more-keywords - pokud existuje nekonečný počet způsobů, jak s obsahem manipulovat, je to skvělé - ale stránky si obvykle zaslouží vlastní URL, nikoli řetězec dotazu a tyto typy Adresám URL je třeba se vyhnout (zkuste přimět někoho, aby negramotně napsal počítač, do kterého zadejte jednu z nich)

20
Metalshark

Řekl bych ne zahrnout příponu souboru, pokud vám software, který používáte, umožňuje vynechat. Takže z vašeho seznamu příkladů bych upřednostňoval:

http://www.somesite.com/subdirectory/some-relevant-keywords

Prohlížeče se nestarají o to, zda je na webu něco, co je adresář, nebo zda se jedná o soubor HTML, soubor ASP nebo cokoli jiného - jednoduše vytvoří požadavek HTTP a obdrží odpověď HTTP. Pokud je rozšíření nadbytečné, vypusťte jej.

To má také další výhodu v tom, že vaše adresy URL jsou stručnější (a snadněji čitelné v telefonu - „příklady produktů s tečkami com slash“ jsou mnohem hezčí než „příklady produktů s tečkami s tečkami dot html“) a usnadňují se technologie přepínání v budoucnu (protože by nebyla nutná žádná změna adresy URL).

13
Tim Fountain

Cool URI se nemění . (Přejděte do části s názvem „Co mám dělat? Navrhování URI“)

12
John Conde

Je upřednostňováno mít příponu souboru nebo ne?

V RFC není nic, co by povolovalo mít přípony souborů, ani nic, co by vyžadovalo jejich vynechání. Je to volba, kterou uděláte.

Konformní HTTP URI nepotřebují přípony souborů pro nic. Existuje bohatá sada záhlaví HTTP (zejména typu MIME), která zpracovávají vše, pro co jsou jinak přípony souborů používány.

Většina dnešních prohlížečů se však při určování typu obsahu ve skutečnosti spoléhá na kombinaci typu MIME, rozšíření a binárního „otisku prstu“ prvních bajtů. Někdy to může dát překvapivé výsledky , a proto je důležité, abychom webmasteři nastavili správná záhlaví (a možná zakázali sniffing typu obsah , pokud jsme si 101% jisti, že naše záhlaví je správné) .

Existuje jedna situace, kdy jsou přípony souborů užitečné: Pokud koncový uživatel uloží obsah z vašeho webu do svého místního počítače pro pozdější použití. „Inteligentní“ prohlížeč by měl teoreticky zajistit, aby uložený obsah fungoval pro typ místního počítače; ale v praxi můžete pomoci všem tím, že obsloužíte obsah s průmyslovými standardními rozšířeními, jako jsou .jpg, .mp4, .css atd. Podle mých zkušeností všechny prohlížeče zpracovávají typ HTML správně. Na HTML nemusíte přidávat příponu .htm/.html sami, prohlížeč bude tento konkrétní typ obsahu zpracovávat správně.

Zabezpečení: Dalo by se argumentovat, že při skrývání platformy, kterou používáte (.php/.asp atd.), Je výhodou zabezpečení. To je pravda. V praxi si myslím, že to každý dobrý hacker hned odhalí, takže si nemyslím, že skrytí těchto rozšíření pro zabezpečení samo o sobě stojí za to.

Zvláštní ohled: Pokud plánujete v budoucnu použít CDN a vaše CDN je typu „Push“ (obsah je předem nahrán na CDN) fx přes SFTP), možná budete chtít zachovat přípony souborů. Většina systémů třetích stran se dívá na přípony souborů a zjišťuje, s jakým typem MIME se bude obsah zobrazovat.

Moje osobní volba se stala:

  • Když HTML generuje dynamicky můj webapp, nepřidávám „falešné“ .html rozšíření, aby napodobovalo strukturu adresářů a souborů, která tam vlastně není. Normalizuji URL a standardizuji formát URL používaný z důvodů SEO. Osobně dávám přednost koncovému lomítku na posledním listu URL, tj. http://example.org/first/second/, ale to je otázka vkusu.

  • Když mluvíme o skutečných souborech, které jsou někde nahrány na pevný disk, ponechám pro tento typ „normální“ příponu souboru. Pro tyto druhy obsahu se tedy používají soubory .css/.js/.exe/.mp4 atd.

8
Jesper Mortensen

Udělal jsem trochu neformální experimenty a to, co jsem objevil, mě překvapilo, ale dávalo to nějaký smysl.

Z hlediska obsahu dodávaného uživateli, stejně jako stírání obrazovky, určuje typ obsahu den.

Zdá se však, že přítomnost nebo nepřítomnost rozšíření, jakož i to, co je toto rozšíření, ovlivňuje návštěvy vyhledávače.

Když jsem vůbec nějaké rozšíření vynechal, dostal jsem relativně málo zásahů - jako by adresa URL byla místem nebo dynamickým obsahem, a proto se za indexování nestojí.

Když jsem změnil stejné odkazy tak, aby používaly příponu .xml, protože stránky byly skutečně generovány pomocí XSLT (na straně serveru), indexování skutečně kleslo dále - snad proto, že se domnívalo, že se jedná pouze o data nebo o výsledek nějaké programové žádosti. .

Když jsem změnil stejné odkazy na použití .html, vyhledávače se s webem rozšířily.

V současné době můj web zpracovává všechny tři transparentně, ale když poskytuje odkaz, na který lze kliknout, vrátím verzi HTML ve formátu HTML.

Rád bych si myslel, že vyhledávače byly trochu chytřejší nebo trochu méně zaujaté, ale to je to, co jsem pozoroval, se stalo s mými stránkami.

2
Walt Stoneburner

Ne, neměli byste používat příponu souboru pro běžné typy stránek, pokud to nepotřebujete z technických důvodů. Jak to zlepší uživatelský dojem? Je to spíš psaní, ale neříká jim nic užitečného. Co budou moci udělat s vědomím, že váš web je PHP, ASP atd.? URL je jednodušší, čistší, použitelnější a zapamatovatelnější bez přípony souboru.

Pokud adresa URL nemá název souboru, je obvykle považována za adresář.

Nemyslím si, že souhlasím. Obecně je URL adresář, pouze pokud má koncové lomítko. Bez koncové lomítko se považuje za soubor.

2
Virtuosi Media

Příponu souboru byste měli přidat pouze v případě, že obsah za URI je ve skutečnosti soubor. Ale i pak byste to mohli zrušit, pokud je to pouze jedna reprezentace (JPG, PDF, ...).

Pokud existuje více reprezentací, cesta HTTP by měla mít vyjednávání formátu prostřednictvím záhlaví Accept. Pokud však chcete, aby vaši uživatelé měli slovo, pravděpodobně byste chtěli rozšíření, aby si mohli vybrat, jakou reprezentaci chtějí (JPG, PNG, ...), vyžádáním jednoho nebo druhého URI.

0
DanMan