Czy to robi różnicę, jeśli ścieżka URL kończy się końcowym ukośnikiem, czy nie?

46

Czy ma to jakikolwiek wpływ na oceny SEO, jeśli Twój adres URL ma ukośnik końcowy:

http://www.example.com/some/slug/paths/

w przeciwieństwie do tych, które nie:

http://www.example.com/some/slug/paths

seo url trailing-slash

— mar10
źródło

1

To samo (teraz zamknięte) pytanie na StackOverflow z kilkoma dobrymi odpowiedziami: ukośnik końcowy w adresach URL - który styl jest preferowany?

— Stephen Ostermiller

38

Przeczytaj pełny post na blogu Google tutaj, http://googlewebmastercentral.blogspot.com/2010/04/to-slash-or-not-to-slash.html , zawiera on dokładnie ten temat.

Krótka historia Google nie dba o to, czy masz końcowy ukośnik. Jednak będzie traktować poniższe 2 ścieżki jako osobne strony.

http://www.example.com/some/slug/paths/
http://www.example.com/some/slug/paths

Jeśli potrzebujesz mieć oba powyższe elementy i mają one tę samą treść, najlepszą opcją jest przekierowanie 301 do jednego z nich od drugiego.

Jeśli nie jest to opcja, będziesz chciał dodać <link rel="canonical" href="your link"/>do obu stron znak, który określi, który jest nadrzędny lub nadrzędny. Matt Cutts ma tutaj świetny artykuł, http://www.mattcutts.com/blog/canonical-link-tag/ , który omawia ten temat w całości.

— Ben Hoffman
źródło

Jest to i tak dobra praktyka, ponieważ nigdy nie wiesz, co ludzie umieszczą jako adres URL podczas linkowania do Ciebie. Nie chciałbym dostać stałego linku do strony PR8, która nie była do mojego kanonicznego adresu URL :)

— Tim Post

3

Nie do tego tak naprawdę służy znacznik kanoniczny. Właściwe jest, aby 301 przekierować wersję ukośnika do wersji bez ukośnika (lub odwrotnie, w zależności od tego, czego chcesz), co dokładnie sugeruje wpis w blogu centralnym Google dla webmasterów, który podłączyłeś. Użyj kanoniki tutaj tylko wtedy, gdy 301 nie jest możliwe.

— Tim Fountain

@Tim - Dobra uwaga. Masz rację, kanoniczny jest tylko rezerwowym wyborem. Zmodyfikowałem swoją odpowiedź, aby była bardziej poprawna. Dzięki!

— Ben Hoffman

1

Aplikacje po stronie serwera również traktują ścieżki inaczej. W Django domena.com/some zostanie przekierowana na domain.com/some/. O czym należy pamiętać. :)

— citadelgrad

9

Oprócz argumentu RandomBen na temat wyszukiwarek traktujących adresy URL z ukośnikiem końcowym w przeciwieństwie do dwóch różnych adresów URL, chciałbym to dodać. Generalnie używam ukośnika końcowego do wskazania kategorii, natomiast nie używam ukośnika końcowego dla stron znajdujących się na końcu lub na dole hierarchii. Slash swoje kategorie, nie tnij niczego innego. Jeśli przepisujesz adresy URL, to najbardziej odpowiada naturalnej strukturze plików. Jednak powinieneś upewnić się, że każda kategoria na twojej ścieżce istnieje, lub możesz skończyć z niektórymi zdezorientowanymi i sfrustrowanymi użytkownikami. W przykładowym adresie URL zarówno „ślimak”, jak i „ślimak” powinny być stronami dostępnymi.

— Virtuosi Media
źródło

To może być całkiem rozsądne. Jeśli chcesz emulować system plików w adresach URL, czy byłoby lepiej, gdybyś „poszedł na całość” i nadał swoim stronom pośredniczącym rozszerzenie (prawdopodobnie fałszywe), takie jak .html lub .py, .pl, .asp , albo coś innego. Brak końcowego ukośnika nie komunikuje mi „strony pośredniej”, można to po prostu zapomnieć - ale robi to rozszerzenie „pliku”.

— Jesper Mortensen

@Jesper „Kto powiedział, że nazwa pliku wymaga rozszerzenia? Spójrz kiedyś na maszynę * nix” - stackoverflow.com/questions/5948659/…

— Yarin

5

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, zalecamy dla uproszczenia pominięcie końcowego ukośnika.

(To jest ta sama odpowiedź, którą opublikowałem na StackOverflow )

— Stephen Ostermiller
źródło

1

Adresy URL z ukośnikami i bez nich są traktowane jako dwa różne adresy URL. Jest to absolutnie niezbędne, aby to naprawić, aby uniknąć powielania problemów z treścią. Zasadniczo wpływa to na całą witrynę, ponieważ każda strona ma duplikat.

Standaryzuj adresy URL w całej witrynie
Użyj 301 przekierowań lub kanonizacji, aby naprawić adresy URL
Przeprowadź wewnętrzny audyt linków, aby upewnić się, że nie ma niepotrzebnych przekierowań, a wszystkie linki wewnętrzne prowadzą do standardowych adresów URL.
Możesz także sprawdzić linki zewnętrzne. Idealnie one również powinny wskazywać na znormalizowane adresy URL.

Zobacz, jak poprawiają się rankingi.

— użytkownik3747257
źródło