Kiedy należy używać końcowego ukośnika w adresie URL? Na przykład - czy mój adres URL powinien wyglądać, /about-us/
czy nie/about-us
?
Jestem w pełni świadomy problemów związanych z SEO - powielania treści i kanoniczności; Próbuję dowiedzieć się, którego powinienem użyć w kontekście prawidłowego wyświetlania stron .
Na przykład mój kolega myśli, że ukośnik na końcu oznacza, że jest to „folder” - „katalog”, więc nie jest to poprawny styl. Ale myślę, że bez ukośnika na końcu - też nie jest całkiem poprawny, ponieważ prawie wygląda jak folder, ale nie jest i nie jest to zwykły plik, ale nazwa pliku bez rozszerzenia.
Czy istnieje właściwy sposób, aby wiedzieć, którego użyć?
Odpowiedzi:
Moim osobistym zdaniem końcowe ukośniki są niewłaściwie używane.
Zasadniczo format adresu URL pochodzi z tego samego formatu plików i folderów UNIX, później w systemach DOS, a na koniec dostosowany do Internetu.
Źródło: Wikipedia: Uniform Resource Identifier
Kolejne dobre źródło do czytania: Wikipedia: URI Scheme
Źródło: Wikipedia Uniform Resource Locator (URL)
Również:
Źródło: Google WebMaster Central Blog - ciąć lub nie ciąć
Wreszcie:
Ukośnik na końcu adresu URL sprawia, że adres wygląda „ładnie”.
Adres URL bez ukośnika na końcu i bez rozszerzenia wygląda nieco „dziwnie”.
Nigdy nie nazwiesz swojego pliku CSS (na przykład) http://www.sample.com/stylesheet/ , prawda?
ALE jestem zwolennikiem najlepszych praktyk internetowych bez względu na środowisko. Może być niepewny i niejasny, tak jak powiedziałeś o adresie URL bez rozszerzenia.
źródło
index.html
(lub o podobnej nazwie pliku), gdy katalog jest dostępny, więc/foo/
jest/foo/index.html
bez dodatkowego bałaganu. Ponadto w przeszłości przeglądarki dodawały się/
do nazwy domeny, ale od tego czasu (Firefox, Chrome, Opera) zmieniły się, aby pominąć/
dostęp do strony głównej.To nie jest kwestia preferencji.
/base
i/base/
mają inną semantykę. W wielu przypadkach różnica jest nieistotna. Ale ważne jest, gdy istnieją względne adresy URL.child
w stosunku do/base/
jest/base/child
.child
względem/base
jest (być może zaskakujące)/child
.źródło
Uri.MakeRelativeUri
. Wyniki odzwierciedlają dokładnie to, co powiedziałeś. Rozwiązałem problem, dodając końcowy ukośnik do mojej bazyUri
.Zawsze jestem zaskoczony szerokim użyciem końcowych ukośników na adresy URL spoza katalogu (między innymi WordPress). To naprawdę nie powinno być debatą ani debatą, ponieważ umieszczenie ukośnika po zasobu jest semantycznie złe. Sieć została zaprojektowana w celu dostarczania zasobów adresowalnych, a adresy te - adresy URL - zostały zaprojektowane do emulacji hierarchii systemu plików w stylu * nix. W tym kontekście:
Korzystając z tych wytycznych, źle jest wstawić ukośnik za zasobem spoza katalogu.
źródło
directory
(w inny sposób,image.png
nahttp://hostname/directory
to wskazująhttp://hostname/image.png
). Mówiłem tylko, że rozróżnienie między plikiem a katalogiem może nie być bardzo ważne z punktu widzenia użytkownika.To nie jest tak naprawdę kwestia estetyki, ale rzeczywiście różnica techniczna. Myślenie o tym w katalogu jest całkowicie poprawne i wyjaśnia wszystko. Sprawdźmy to:
Jesteś teraz w epoce kamienia łupanego lub wyświetlasz tylko statyczne strony
Masz stałą strukturę katalogów na swoim serwerze WWW i tylko pliki statyczne, takie jak obrazy, HTML itp. - Żadnych skryptów po stronie serwera ani żadnych innych.
Przeglądarka żąda
/index.htm
, istnieje i jest dostarczana do klienta. Później masz wiele - powiedzmy - sprawdzonych filmów DVD i stronę html dla każdego z nich w/dvd/
katalogu. Teraz ktoś prosi/dvd/adams_apples.htm
i jest dostarczany, ponieważ on tam jest.Pewnego dnia ktoś po prostu pyta
/dvd/
- który jest katalogiem, a serwer próbuje dowiedzieć się, co dostarczyć. Oprócz ograniczeń dostępu i tak dalej istnieją dwie możliwości: pokazać użytkownikowi zawartości katalogów (założę się, że już to gdzieś widziałem) lub pokazać plik domyślny (w Apache jest:DirectoryIndex: sets the file that Apache will serve if a directory is requested.
)Jak dotąd tak dobrze, jest to oczekiwany przypadek.Już pokazuje różnicę w obsłudze, więc przejdźmy do tego:
O 5:34 popełniłeś błąd podczas przesyłania plików
(Nawiasem mówiąc, jest to całkowicie zrozumiałe.) Więc zrobiłeś coś zupełnie nie tak i zamiast przesyłać
/dvd/the_big_lebowski.htm
ten plik przesłałeś jakodvd
(bez rozszerzenia) do/
.Ktoś dodał zakładkę do twojego
/dvd/
katalogu (oczywiście, że nie chciałeś tworzyć i zawsze aktualizować tego sprytnegoindex.htm
) i odwiedza twoją stronę internetową. Zawartość katalogu jest dostarczana - wszystko w porządku.Ktoś usłyszał o twojej liście i pisze
/dvd
. A teraz jest przykręcony. Zamiast wykazu katalogu DVD serwer znajduje plik o tej nazwie i dostarcza plik Big Lebowski.Więc usuwasz ten plik i każesz facetowi ponownie załadować stronę. Twój serwer szuka
/dvd
pliku, ale go nie ma. Większość serwerów zauważy wtedy, że istnieje katalog o tej nazwie i powie klientowi, że to, czego szukał, jest rzeczywiście gdzie indziej. Odpowiedź najprawdopodobniej będzie następująca:Status Code:301 Moved Permanently
zLocation: http://[...]/dvd/
Całkowicie ignorując to , co ty myślisz o katalogach lub plikach, serwer może obsługiwać tylko takie rzeczy i - o ile nie powiedziano inaczej - decyduje o znaczeniu „slash or not”.
W końcu po otrzymaniu tej odpowiedzi klient ładuje się
/dvd/
i wszystko jest w porządku.Czy to w porządku? Nie.
„W porządku” nie jest dla ciebie wystarczająco dobre
Masz dynamiczną stronę, na której wszystko jest przekazywane
/index.php
i przetwarzane. Do tej pory wszystko działało całkiem dobrze, ale wszystko zaczęło się spowalniać, a Ty badasz.Wkrótce zauważysz, że
/dvd/list
robi to dokładnie to samo: przekierowanie, na/dvd/list/
które jest następnie wewnętrznie tłumaczoneindex.php?controller=dvd&action=list
. Jedna dodatkowa prośba - ale jeszcze gorzej!customer/login
przekierowuje nacustomer/login/
które z kolei przekierowuje na adres URL HTTPScustomer/login/
. W efekcie powstaje mnóstwo niepotrzebnych przekierowań HTTP (= dodatkowe żądania), które spowalniają działanie użytkownika.Najprawdopodobniej masz tutaj również domyślny indeks katalogów:
index.php?controller=dvd
bezaction
wewnętrznego ładowaniaindex.php?controller=dvd&action=list
.Podsumowanie:
Jeśli się skończy
/
, nigdy nie będzie plikiem. Bez zgadywania serwera.Slash lub no slash mają zupełnie inne znaczenia. Istnieje różnica techniczna / związana z zasobami między „cięciem lub bez cięcia” i powinieneś być tego świadomy i odpowiednio go używać. Tylko dlatego, że serwer najprawdopodobniej ładuje
/dvd/index.htm
- lub ładuje poprawne skrypty - kiedy mówisz/dvd
: Robi to, ale nie dlatego, że zrobiłeś właściwe żądanie. Co by było/dvd/
.Pominięcie ukośnika, nawet jeśli naprawdę masz na myśli wersję ukośną, powoduje dodatkową karę za żądanie HTTP. Co jest zawsze złe (pomyśl o opóźnieniu na urządzeniach mobilnych) i ma większą wagę niż „ładny URL” - zwłaszcza, że roboty nie są tak głupie, jak wierzą SEO lub chcą, abyś uwierzył;)
źródło
dvd
)?Po dokonaniu swój adres URL
/about-us/
(z ukośnik), łatwo zacząć z jednym plikuindex.html
, a później go rozwinąć i dodać kolejne pliki (npour-CEO-john-doe.jpg
) lub nawet zbudować hierarchię pod nim (np/about-us/company/
,/about-us/products/
etc.) w razie potrzeby, bez zmiana opublikowanego adresu URL . Zapewnia to dużą elastyczność.źródło
/about-us
lub/about-us/
nadal muszę zmienić opublikowany adres URL w obu przypadkach, jeśli rozwinąłem katalog. nowy plik będzie/about-us/new-file.html
w obu przypadkach !! czego tu brakuje?/about-us
i/about-us/company
? Jeśli chodzi o podawanie plików, zarówno Apache, jak i IIS mogą sobie z tym poradzić, więc się nie zgadzam./about-us
chcesz link do/about-us/company
, musisz użyćhref="https://stackoverflow.com/about-us/company"
lubhref="./company"
(choć nie jestem pewien co do tego). Jeśli jesteś/about-us/
, chociaż, to proste:href="company"
.Inne odpowiedzi tutaj wydają się przemawiać za pominięciem końcowego slasha. Jest jeden przypadek, w którym końcowy ukośnik pomoże w optymalizacji pod kątem wyszukiwarek (SEO). Tak jest w przypadku, gdy dokument ma rozszerzenie, które wydaje się nie mieć takiego rozszerzenia
.html
. Staje się to problemem w przypadku witryn, które oceniają witryny. Mogą wybierać między tymi dwoma adresami URL:http://mysite.example.com/rated.example.com
http://mysite.example.com/rated.example.com/
W takim przypadku wybrałbym ten z końcowym ukośnikiem . Jest tak, ponieważ
.com
rozszerzenie jest rozszerzeniem plików poleceń wykonywalnych systemu Windows. Wyszukiwarki i programy sprawdzające wirusy często nie lubią adresów URL, które wydają się zawierać złośliwe oprogramowanie rozpowszechniane za pośrednictwem takich mechanizmów. Końcowy ukośnik wydaje się łagodzić wszelkie obawy, pozwalając stronie pozycjonować się w wyszukiwarkach i sprawdzać się przez wirusy.Jeśli twoje adresy URL nie mają
.
w części pliku, to dla uproszczenia zalecamy pominięcie końcowego ukośnika.źródło
Kto powiedział, że nazwa pliku wymaga rozszerzenia? spójrz kiedyś na maszynę * nix ...
Zgadzam się z twoim przyjacielem, bez końcowego ukośnika.
źródło
Z punktu widzenia SEO wybór, czy dodać końcowy ukośnik na końcu adresu URL, jest nieistotny. W dzisiejszych czasach przykłady obu można znaleźć w Internecie. Witryna nie będzie karana w żaden sposób, ani ten wybór nie wpłynie na pozycję witryny w rankingu wyszukiwarki ani na inne kwestie związane z SEO.
Wystarczy wybrać preferowaną konwencję nazewnictwa adresów URL i dołączyć kanoniczny metatag w
<head>
sekcji każdej strony internetowej.Wyszukiwarki mogą uznać pojedynczą stronę jako dwa oddzielne zduplikowanych adresów URL, kiedy spotykają ją i bez ukośnika, czyli
example.com/about-us/
aexample.com/about-us
.Najlepszą praktyką jest umieszczanie kanonicznego metatagu na każdej stronie, ponieważ nie można kontrolować, w jaki sposób inne witryny prowadzą do twoich adresów URL.
Znacznik kanoniczny wygląda następująco:
<link rel="canonical" href="https://example.com/about-us" />
. Zastosowanie kanonicznego metatagu zapewnia, że wyszukiwarki zliczają każdy z adresów URL tylko raz, niezależnie od tego, czy inne witryny zawierają ukośnik końcowy, gdy prowadzą do Twojej witryny.źródło