Kiedy powinienem używać ukośnika końcowego w moim adresie URL?

283

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ć?

— Denis
źródło

Końcowy slash, ale moim zdaniem to głównie estetyka. Widzieć i czuć.

— Eric Herlitz,

3

To samo pytanie dla webmasterów Pro: czy to robi różnicę, jeśli twoja ścieżka URL kończy się ukośnikiem, czy nie?

— Stephen Ostermiller

4

To pytanie jest postawione jako preferencyjne i dlatego wydaje się być nie na temat, ponieważ opiera się głównie na opiniach . Jednak, jak pokazuje moja odpowiedź , w rzeczywistości postawienie tego pytania na zasadzie preferencji jest błędem: jest to problem XY, a leżące u jego podstaw „prawdziwe” pytanie ma precyzyjną odpowiedź techniczną, a zatem nie opiera się głównie na opiniach .

— Raedwald

Pytania o typy adresów URL polubionych przez Google nie są związane z programowaniem (jak wspomniano w tagu wiki ) i są nie na temat w Stackoverflow.

— Quentin

Wprowadziłem kilka zmian w Twoim pytaniu, proszę dokładnie je sprawdzić, jeśli masz taką możliwość. Dzięki :)

— Tim Post

131

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.

Typowym adresem URL tej książki w systemie operacyjnym uniksowym jest ścieżka do pliku, taka jak file: ///home/username/RomeoAndJuliet.pdf, identyfikująca książkę elektroniczną zapisaną w pliku na lokalnym dysku twardym.

Źródło: Wikipedia: Uniform Resource Identifier

Kolejne dobre źródło do czytania: Wikipedia: URI Scheme

Zgodnie z RFC 1738, która zdefiniowała adresy URL w 1994 r., Gdy zasoby zawierają odniesienia do innych zasobów, mogą używać linków względnych do definiowania lokalizacji drugiego zasobu, jakby to powiedzieć: „w tym samym miejscu co ten, z wyjątkiem następujących krewnych ścieżka". Dalej powiedziano, że takie względne adresy URL są zależne od pierwotnego adresu URL zawierającego hierarchiczną strukturę, na której opiera się względny link, oraz że schematy ftp, http i plików URL są przykładami niektórych, które można uznać za hierarchiczne, z składniki hierarchii są oddzielone „/”.

Źródło: Wikipedia Uniform Resource Locator (URL)

Również:

To pytanie często słyszymy. Dalej do odpowiedzi! Historycznie rzecz biorąc, adresy URL z ukośnikiem końcowym często wskazują katalog, a te bez ukośnika - plik:

http://example.com/foo/ (z końcowym ukośnikiem, konwencjonalnie katalogiem)

http://example.com/foo (bez ukośnika, konwencjonalnie plik)

Ź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.

— Demencja
źródło

1

To dziwne, nie można nazwać pliku „arkusz stylów /” - a ukośnik lub ukośnik to zupełnie inne zasoby na serwerze, bez względu na to, jak wygląda adres URL

— nico gawenda

10

@nicogawenda, .htaccess potrafi robić wszelkiego rodzaju magię;) Twój CSS może być plikiem php!

— rmorse 16.04.13

4

Serwery WWW są często domyślnie skonfigurowana, aby służyć index.html(lub o podobnej nazwie pliku), gdy katalog jest dostępny, więc /foo/jest /foo/index.htmlbez 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.

— 0b10011

4

Zgadzam się z @bfrohs. Z pewnością domyślne strony katalogów są sprzeczne z tą zasadą. Jeśli mamy wymusić „trailing slash = katalog”, to z pewnością wszystkie adresy URL wskazujące na katalog muszą zwrócić listę katalogów lub 403 zabronioną odpowiedź http.

— Marvin

11

Nie jestem pewien, czy punkty 1 i 2 w sekcji „Wreszcie” są nadal dokładne. Z biegiem lat, odkąd został napisany, gusta się zmieniły. Nie badałem tego szczegółowo, ale wydaje się, że w nowszych witrynach częściej i „ładniej” jest pominąć slash.

— Speedplane

172

To nie jest kwestia preferencji. /basei /base/mają inną semantykę. W wielu przypadkach różnica jest nieistotna. Ale ważne jest, gdy istnieją względne adresy URL.

childw stosunku do /base/jest /base/child.
childwzględem /basejest (być może zaskakujące) /child.

— Raedwald
źródło

5

Pomocny artykuł na ten temat: cdivilly.wordpress.com/2014/03/11/…

— Hefajstos

3

Tak, myślę, że to, wraz z SEO, są najważniejsze w tym pytaniu.

— user2875289,

Właśnie przeszedłem ten problem podczas korzystania z .Net Uri.MakeRelativeUri. Wyniki odzwierciedlają dokładnie to, co powiedziałeś. Rozwiązałem problem, dodając końcowy ukośnik do mojej bazy Uri.

— julealgon

61

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:

Ukośniki zawsze oznaczają katalogi, nigdy plików.
Pliki mogą mieć dowolne nazwy (z rozszerzeniami lub bez), ale nie mogą zawierać ani kończyć się ukośnikami.

Korzystając z tych wytycznych, źle jest wstawić ukośnik za zasobem spoza katalogu.

— Yarin
źródło

50

„ukośniki po katalogach, a nie po zasobach”: adresy URL nie odnoszą się do dwóch rodzajów rzeczy, „zasobów” i „katalogów”; odnoszą się do jednego rodzaju rzeczy: zasobów. Wskazówka znajduje się w R adresu URL.

— Raedwald

31

I wszystko w systemie plików * nix jest plikiem, ale katalogi nadal istnieją. O co ci chodzi?

— Yarin

6

Niezależnie od tego, czy jest obsługiwany wewnętrznie przez plik, czy katalog, użytkownik widzi tylko stronę internetową. I example.com/about może faktycznie czytać z example.com/about/index.html .

— musiphil

1

@DavidRR: Masz rację. A przeglądarka musi przekierowanie ponieważ uchwała nazwa musi się zdarzyć od wewnątrz directory(w inny sposób, image.pngna http://hostname/directoryto 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.

— musiphil

2

Zgadzam się z twoim wynikiem, ale nie jestem pewien, czy powinniśmy projektować nasz system URL, aby emulować systemy plików w stylu * nix. Mogło to kiedyś służyć celowi, ale teraz znacznie mniej.

— speedplane

27

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.htmi 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.htmten plik przesłałeś jako dvd(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 /dvdpliku, 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 z Location: 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.phpi 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/listrobi to dokładnie to samo: przekierowanie, na /dvd/list/które jest następnie wewnętrznie tłumaczone index.php?controller=dvd&action=list. Jedna dodatkowa prośba - ale jeszcze gorzej! customer/loginprzekierowuje na customer/login/które z kolei przekierowuje na adres URL HTTPS customer/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=dvdbez actionwewnętrznego ładowania index.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ł;)

— Nico Gawenda
źródło

2

Podsumowując, czy jesteście wszyscy za dodaniem ukośnika na końcu? :)

— Denis

2

Jestem za używaniem tego, co masz na myśli;) Na przykład mówiąc o kontrolerach i działaniach byłoby to: Kontrolery powinny kończyć się ukośnikiem. Kiedy odwołujesz się do pliku lub akcji, pomiń slash

— nico gawenda

Poczekaj, dlaczego miałbyś pominąć cięcie za akcję? Czy w twoim przykładzie nie spowoduje to dodatkowego przekierowania? Mam na myśli, że prawdopodobnie twój serwer jest wystarczająco inteligentny, aby rozpoznać działanie kontrolera i nie przekieruje w celu wyszukania plików lub katalogów w takim przypadku, ale nadal nie zgadza się z twoim przykładem, prawda?

— Adam Goodwin,

7

Nie rozumiem twojego przykładu. Jaki system plików dopuszcza katalog i inny zwykły plik o tej samej nazwie ( dvd)?

— musiphil

19

Po dokonaniu swój adres URL /about-us/(z ukośnik), łatwo zacząć z jednym pliku index.html, a później go rozwinąć i dodać kolejne pliki (np our-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ść.

— musiphil
źródło

9

Przepraszam, nie rozumiem. jeśli zacznę od /about-uslub /about-us/nadal muszę zmienić opublikowany adres URL w obu przypadkach, jeśli rozwinąłem katalog. nowy plik będzie /about-us/new-file.htmlw obu przypadkach !! czego tu brakuje?

— Księgowy م

2

@Accountant Myślę, że OP może myśleć, że jeśli opublikujesz „/ about-us” bez końcowego ukośnika, nie będziesz mógł później dodać pod-zasobów używając względnych ścieżek. Jeśli nie masz końcowego ukośnika, przeglądarka uwierzy, że odniesienie do „ceo.jpg” na stronie about będzie dostępne w katalogu głównym domeny i zażąda example.com/ceo.jpg. Za pomocą ukośnika przeglądarka zażąda example.com/about-us/ceo.jpg, a po rozwinięciu możesz statycznie trasować całe drzewo folderów dla swojej witryny.

— daw

1

Do waszej informacji - Nie wierzę, że którekolwiek z powyższych jest prawdą - Dlaczego nie może być /about-usi /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.

— sean2078

1

@ sean2078 Tak, ale jeśli /about-uschcesz link do /about-us/company, musisz użyć href="https://stackoverflow.com/about-us/company"lub href="./company"(choć nie jestem pewien co do tego). Jeśli jesteś /about-us/, chociaż, to proste: href="company".

— Adowrath

11

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ż .comrozszerzenie 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.

— Stephen Ostermiller
źródło

Żadne prawdziwe wyszukiwarki nie są tak głupie. Ta odpowiedź jest czystą spekulacją.

— Navin

1

Tak naprawdę widziałem ten problem z Google. To było kilka lat temu, więc nie jestem pewien, czy nadal tak będzie dzisiaj.

— Stephen Ostermiller

Huh, to dobry punkt danych. Chociaż nadal nie wiemy, czy było to spowodowane czymś innym.

— Navin

10

Kto powiedział, że nazwa pliku wymaga rozszerzenia? spójrz kiedyś na maszynę * nix ...
Zgadzam się z twoim przyjacielem, bez końcowego ukośnika.

— Aaron Gage
źródło

3

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/a example.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.

— zamieszki
źródło