Czy powinienem używać rozszerzenia pliku, czy nie?

Zawsze się nad tym zastanawiałem i nigdy nie znalazłem dobrego rozwiązania.

Ale to pytanie mi to przypomniało.

Kiedy mam adres URL w mojej witrynie, można go wyświetlić i uzyskać do niego dostęp w dowolny z następujących sposobów:

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

itp...

Teraz rozumiem zalety dodawania słów kluczowych w adresie URL. Nawet najbardziej podstawowy przewodnik SEO wspomina, aby to zrobić. ... ale ze względu na poczytalność, przejrzystość, łatwość czytania, łatwość użytkowania itd., w tym zgodność z Internetem ...

Jest to korzystne , aby mieć plik-extension czy nie?

Naprawdę, głęboko w mojej logice mówi mi: tak, powinno. Wynika to z przeszłości, kiedy internet był w większości USENET, FIDONET, FTP i GOPHER.

Zobacz, jeśli adres URL nie ma nazwy pliku , wówczas zwykle jest uważany za katalog . To tutaj powstał index.htm, ponieważ domyślnie wyświetla katalog, jeśli nie znaleziono pliku indeksu. Wkrótce jednak programiści WWW zaczęli to zastępować i używać index.htm, aby faktycznie wyświetlać zawartość tego katalogu jako stronę . Główną różnicą było dodanie języka znaczników, który został przeanalizowany w przeglądarce. W tym języku znaczników Content-Type:text/html;znacznik w nagłówku odpowiedzi stał się wskaźnikiem typu pliku dla dowolnego pliku . HTML wydaje się być jedynym „typem pliku”, który po prostu nie ma konsekwentnie nazwanych rozszerzeń, z wyjątkiem sytuacji, gdy są zapisywane.

Niestety, gdy strony internetowe stały się najważniejsze, wyświetlenie zawartości katalogu stało się błędem bezpieczeństwa, więc wszystko pozostało ukryte, a wyświetlana była tylko rzeczywista treść adresu URL.

Nie wspominając o wieloplatformowych wojnach nazewnictwa plików. Oparte na systemie Windows wymagają 3 lub mniej cyfrowego rozszerzenia, a unix / mac może mieć więcej. Więc powinno być .HTMalbo .HTMLalbo NONEi niech platforma zdecydować?

Zasadniczo sądzę, że to, co próbuję ustalić, wykracza poza SEO i zajmuje się bardziej estetyką i zgodnością z Internetem.

Użyj .extension, jeśli istnieje więcej niż jedna reprezentacja lub gdy oprogramowanie klienckie jest absolutnie głupie i odmawia zaakceptowania samego rodzaju zawartości (QuickTime, RealPlayer, Outlook itp. Patrzę na ciebie):

• http://www.somesite.com/subdirectory - może to być Twoja wersja z automatyczną negocjacją, która używa kanonicznych tagów META do wskazania rzeczywistej reprezentacji

• http://www.somesite.com/subdirectory/ - zawsze warto wspierać końcowe ukośniki na dowolnym adresie URL, ale używając kanonicznych tagów META (nie przekierowuje, ponieważ jest to niepotrzebne spowolnienie), aby wskazać prawidłowy adres URL

• http://www.somesite.com/subdirectory/index.htmoraz http://www.somesite.com/subdirectory/some-relevant-keywords.htm- trzyliterowy limit rozszerzenia nie dotyczy HTTP (tylko bazowy system plików / system operacyjny), więc klient może zapisać go jako index.html lub aa, jeśli chce, i nadal mieć do niego dostęp

• http://www.somesite.com/subdirectory/index.html - jeśli podajesz wersję .atom, .xml lub podobną, wówczas warto również honorować wersję .html (i kanonicznie link do niej za pomocą tagów LINK w wersji automatycznie negocjowanej) - użyj nagłówków HTTP Content-Location, aby wskazać do wersji z automatyczną negocjacją - pamiętaj jednak, że możesz także korzystać z wersji wielojęzycznej (.en, .es itp.) lub wielu znaków (.utf8, .utf16 itp.)

• http://www.somesite.com/subdirectory/index.phporaz http://www.somesite.com/subdirectory/index.asp- o ile nie podajesz kodu źródłowego, nie ma to sensu wspierać

• http://www.somesite.com/subdirectory/some-relevant-keywords - SEO to ciągle zmieniająca się sztuka, a jeśli to działa, to świetnie

• http://www.somesite.com/subdirectory/index.php?page=some-relevant-keywords, http://www.somesite.com/subdirectory/?page=some-relevant-keywordsi http://www.somesite.com/subdirectory/?page=some-relevant-keywords&even=more-keywords- jeśli istnieje nieskończona liczba sposobów manipulowania treścią, jest to świetne - ale zwykle strony zasługują na swój własny adres URL, a nie ciąg zapytania i tego typu adresów URL należy unikać (spróbuj skłonić kogoś niepiśmiennego do pisania jednego z nich te w)

Powiedziałbym, że nie dołączaj rozszerzenia pliku, jeśli oprogramowanie, którego używasz, pozwala je pominąć. Zatem z listy przykładów preferuję:

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

Przeglądarki nie dbają o to, czy coś jest katalogiem w witrynie, czy nie, czy jest to plik HTML, .asp lub cokolwiek innego - po prostu wysyłają żądanie HTTP i otrzymują odpowiedź HTTP. Więc jeśli rozszerzenie jest zbyteczne, upuść je.

Ma to również tę dodatkową zaletę, że sprawia, że ​​adresy URL są bardziej zwięzłe (i łatwiejsze do odczytania na telefonie - „przykładowe produkty z kropkami com slash” brzmi o wiele ładniej niż „przykładowe produkty z kropkami com kropka htm l”) i ułatwiają zmienić technologię w przyszłości (ponieważ zmiana adresu URL nie byłaby wymagana).

Fajne identyfikatory URI się nie zmieniają . (Przejdź do sekcji zatytułowanej „Więc co powinienem zrobić? Projektowanie identyfikatorów URI”)

Czy lepiej jest mieć rozszerzenie pliku, czy nie?

W RFC nie ma niczego, co nakazałoby mieć rozszerzenia plików, ani nie ma niczego, co wymagałoby ich pominięcia. To twój wybór.

Zgodne identyfikatory URI HTTP do niczego nie potrzebują rozszerzeń plików. Istnieje bogaty zestaw nagłówków HTTP (zwłaszcza typu MIME) do obsługi wszystkiego, do czego rozszerzenia plików są używane.

To powiedziawszy, większość dzisiejszych przeglądarek faktycznie polega na kombinacji typu MIME, rozszerzenia i binarnego „odcisku palca” pierwszych bajtów w celu określenia typu zawartości. Czasami może to dać zaskakujące wyniki , dlatego tak ważne jest, abyśmy webmasterzy ustawili odpowiednie nagłówki (i ewentualnie wyłączali wąchanie typu zawartości, jeśli mamy 101% pewności, że nasze nagłówki są poprawne).

Istnieje jedna sytuacja, w której rozszerzenia plików są przydatne: Jeśli użytkownik końcowy zapisuje zawartość witryny na swoim komputerze lokalnym w celu późniejszego wykorzystania. Teoretycznie „inteligentna” przeglądarka powinna zapewnić, że zapisana zawartość działa na komputerze lokalnym; ale w praktyce możesz pomóc każdemu, udostępniając treści ze standardowymi rozszerzeniami, takimi jak .jpg, .mp4, .css itp. Z mojego doświadczenia wynika, że ​​wszystkie przeglądarki poprawnie obsługują typ HTML. Nie musisz samodzielnie dodawać rozszerzenia .htm / .html do HTML, przeglądarka poprawnie obsłuży ten konkretny typ zawartości.

Bezpieczeństwo: Można argumentować, że ukrywanie używanej platformy (.php / .asp itp.) Jest korzystne dla bezpieczeństwa. To prawda. W praktyce myślę, że każdy dobry haker odkryje to od razu, więc nie sądzę, aby ukrywanie tych rozszerzeń dla bezpieczeństwa było warte kłopotów.

Szczególna uwaga: jeśli planujesz korzystać z CDN w przyszłości, a Twój CDN jest typu „push” (zawartość jest wcześniej przesyłana do CDN za pośrednictwem SFTP), możesz chcieć zachować rozszerzenia plików. Większość systemów innych firm analizuje rozszerzenia plików, aby dowiedzieć się, z jakim typem MIME można obsługiwać zawartość.

Mój osobisty wybór stał się:

• Gdy HTML jest generowany dynamicznie przez moją aplikację internetową, nie dodam „fałszywego” rozszerzenia .html w celu naśladowania struktury katalogów i plików, których tak naprawdę nie ma. Normalizuję adresy URL i standaryzuję format adresów URL używany ze względu na SEO. Osobiście wolę mieć ukośnik na ostatnim liściu adresu URL, tj. http://example.org/first/second/, Ale to kwestia gustu.

• Kiedy w rzeczywistości mówimy o rzeczywistych plikach, które są gdzieś przesyłane na dysk twardy, zachowuję „normalne” rozszerzenie pliku dla tego typu. Tak więc .css / .js / .exe / .mp4 itp. Są używane do tego rodzaju treści.

Przeprowadziłem trochę nieformalne eksperymenty i to, co odkryłem, zaskoczyło mnie, ale ma pewien sens.

Z punktu widzenia dostarczania treści do użytkownika, a także skrobania ekranu, Content-Type rządzi dniem.

Jednak obecność lub brak rozszerzenia, a także jego rozszerzenie, wydają się wpływać na wizyty w wyszukiwarkach.

Kiedy w ogóle pominąłem jakieś rozszerzenie, otrzymałem stosunkowo mało trafień - tak jakby adres URL był lokalizacją lub treścią dynamiczną i dlatego nie byłby warty indeksowania.

Kiedy zmieniłem te same linki, aby użyć rozszerzenia .xml, ponieważ strony zostały wygenerowane przez XSLT (po stronie serwera), indeksowanie faktycznie spadło dalej - być może dlatego, że myślałem, że to tylko dane lub wynik jakiegoś programowego żądania .

Kiedy zmieniłem te same linki, aby używać .html, wyszukiwarki oszalały na stronie.

W tej chwili moja witryna obsługuje wszystkie trzy w sposób przejrzysty, ale gdy zawiera link, który można kliknąć, zwracam wersję .html adresu URL.

Chciałbym myśleć, że wyszukiwarki były trochę mądrzejsze lub nieco mniej stronnicze, ale to właśnie zaobserwowałem na moich stronach.

Nie, nie powinieneś używać rozszerzenia pliku dla normalnych typów stron, chyba że jest to absolutnie potrzebne ze względów technicznych. Jak to poprawia komfort użytkowania? To więcej do pisania, ale nie mówi im nic pożytecznego. Co będą mogli zrobić, wiedząc, że Twoja witryna to PHP, ASP itp.? Adres URL jest prostszy, czystszy, bardziej użyteczny i bardziej niezapomniany bez rozszerzenia pliku.

Zobacz, jeśli adres URL nie ma nazwy pliku, wówczas zwykle jest uważany za katalog.

Nie sądzę, że się zgadzam. Zasadniczo adres URL jest katalogiem tylko wtedy, gdy ma ukośnik końcowy. Bez końcowego ukośnika jest uważany za plik.

Należy dodać rozszerzenie pliku tylko wtedy, gdy zawartość za URI jest w rzeczywistości plikiem. Ale nawet wtedy możesz go upuścić, jeśli jest tylko jedna jego reprezentacja (JPG, PDF, ...).

Jeśli istnieje wiele reprezentacji, sposobem HTTP byłoby wynegocjowanie formatu przez Acceptnagłówek. Ale jeśli chcesz, aby Twoi użytkownicy mieli coś do powiedzenia, prawdopodobnie będziesz chciał mieć rozszerzenie, aby mogli wybrać żądaną reprezentację (JPG, PNG, ...), żądając jednego lub drugiego identyfikatora URI.