URL z ukośnikiem lub bez - dlaczego tak jest?

1. Ogólna składnia adresu URL
2. Schematy hierarchiczne
3. Ogólna składnia schematu sieci
4. Hierarchia
5. Http
6. Formalny zapis
7. Wniosek
8. Dla twojej informacji
9. Co jeszcze można przeczytać na temat SEO

Spory w tej kwestii - jak poprawnie pisać adresy URL, z ukośnikiem lub bez ukośnika na końcu? - były i będą. Argument ten jest zróżnicowany i często kontrowersyjny. A płacenie za nieprawidłowy wpis uniwersalnego lokalizatora zasobów (URL) jest dwojakiego rodzaju. Ze strony wyszukiwarek - to rzekomo kary za duplikaty stron. Z punktu widzenia wydajności jest to rzekomo dodatkowe przekierowanie do właściwej strony wejściowej, która jest automatycznie generowana przez serwer.

Jednak patrząc na specyfikacje techniczne standardów internetowych, w szczególności dokument „ RFC 1738 - Jednolite lokalizatory zasobów (URL) ”, musimy przyznać, że obie opcje zapisu adresu zasobu internetowego są formalnie poprawne, a sankcja za użycie jednej lub drugiej opcji jest niczym więcej jak wyszukiwarką lub pseudo-SEO historiami.

Z pozycji zwięzłości opcja bez ukośnika na końcu wydaje się być bardziej poprawna, niezależnie od tego, czy link odnosi się do pliku na serwerze lub do folderu, czego pośrednie dowody zostaną przedstawione poniżej. Ale w dokumencie nie ma ani jednego stwierdzenia, że ​​inna opcja jest niepoprawna lub odnosi się do zupełnie innego zasobu.

Nie prześlę Ci tłumaczenia wielostronicowego wspomnianego RFC, ponieważ, po pierwsze, celem pytania były ukośniki na końcu adresu URL, a po drugie, publikacja jest skierowana do prostych użytkowników silników, w tym Impera cms dla których wszystkie szczegóły nie są interesujące, czekają na krótkie wyjaśnienia i dowody rzeczowe. W związku z tym przytoczę fragmenty tego dokumentu jako bazę dowodową i wyjaśnię. Komu i to nie jest interesujące, możesz od razu zobaczyć wyjście na końcu artykułu.

Ogólna składnia adresu URL

Najpierw zwróć uwagę na fragment z akapitu. 2. Ogólna składnia adresu URL (ogólna składnia adresu URL). W każdym przypadku podam fragment tekstu w języku oryginalnym, a następnie tłumaczenie na język rosyjski.

Adresy URL służą do lokalizowania zasobów, zapewniając abstrakcyjną identyfikację lokalizacji zasobów. Adresy URL służą do „lokalizowania” zasobów, zapewniając abstrakcyjne wskazanie lokalizacji zasobu.

Oznacza to, że sam adres URL jest czystą abstrakcją. To, że może nam się wydawać, że przypominamy zewnętrznie nazwę pliku lub folderu, wcale nie oznacza fizycznego wskazania takiego pliku, a nie żadnego innego w przestrzeni plików serwera. Poniżej w dokumencie zostanie to podane bezpośrednio.

Uwaga Ogólnie rzecz biorąc, w odniesieniu do łączy http, na przykład, błędne jest mówienie tego

• http://domain.com/path/subpath/filename.txt - rzekomo wskazuje na plik
• http://domain.com/path/subpath/ - rzekomo wskazuje na folder
• http://domain.com/path - rzekomo niepoprawnie wskazuje na folder

Przyzwyczailiśmy się do tego mówić, ponieważ wygodnie jest powiązać linki z plikami na stronie. W rzeczywistości wszystkie te łącza wskazują na niektóre zasoby, bez jakiegokolwiek oznaczania typu zasobu. To, co kryje się za każdym zasobem, to znaczy, jaki rodzaj prawdziwego pliku lub folderu oraz jaki rodzaj treści zostanie przekazany za pośrednictwem takiego łącza, jest już określone przez konfigurację serwera.

Ważne jest, aby zrozumieć, że linki nie mają czegoś takiego jak „plik”, „folder”, „podfolder”, „tekst”, „obraz”, „html”, „skrypt”, „arkusz stylów” i tak dalej. Brak ukośnika na końcu lub jego brak nic nie znaczy, dopóki łącze nie przejdzie transformacji wewnątrz serwera, a on już decyduje o tym, gdzie właściwie wskazuje łącze i jaki rodzaj treści jest ukryty za nim. Tylko to rozwiązanie odnosi się do wewnętrznej architektury serwera.

Schematy hierarchiczne

Dalsze fragmenty akapitu 2.3 Schematy hierarchiczne i odnośniki względne (schematy hierarchiczne i odnośniki względne).

Niektóre schematy URL (takie jak ftp, http i schematy plików) zawierają hierarchię; Składniki hierarchii są oddzielone przez „/”. Niektóre schematy URL (takie jak ftp, http i plik) zawierają nazwy, które można uznać za hierarchiczne; elementy hierarchii są oddzielone przez „/”.

Oznacza to, że w indywidualnych schematach adresowych treść lokalizatora zasobów nie może oznaczać hierarchii, i jak dotąd nie określono, że hierarchia jest równoważna jakiejkolwiek formie, powiedzmy plik.

Ogólna składnia schematu sieci

Dalsze fragmenty akapitu 3.1. Składnia wspólnego schematu internetowego (ogólna składnia schematu sieci).

// <użytkownik>: <hasło> @ <host>: <port> / <ścieżka_url> "<użytkownik>: <hasło> @", ": <hasło>", ": < port> ”, a„ / <ścieżka_url> ”może zostać wykluczona. Niektóre lub wszystkie części „<użytkownik>: <hasło> @”, „: <hasło>”, „: <port>” i „/ ścieżka_urazowa” mogą zostać pominięte.

To jest, nawiasem mówiąc, odpowiedź na pytanie wywodzące się z pytania, które rozważamy. Często dyskutuje się na takie pytanie: jak poprawnie podać link do domeny (hosta) - bez ukośnika na końcu lub ukośnikiem?

Jak jest poprawny http://domain.com/ lub http://domain.com?

I tak jest dobrze. Tylko pierwszy ukośnik po nazwie hosta ma na celu oddzielenie nazwy ścieżki od nazwy hosta. Ten sam akapit dokumentu informuje o tym w następujący sposób:

url-path jest ścieżką url. Można uzyskać do niego dostęp. Zauważ, że „/” nie jest częścią ścieżki url. Reszta lokalizatora składa się z danych specyficznych dla schematu i jest znana jako „ścieżka url” (ścieżka URL). Zawiera szczegółowe informacje na temat dostępu do określonego zasobu. Zauważ, że znak „/” między hostem (lub portem) a ścieżką URL nie jest częścią ścieżki url.

Nie zobowiązali cię do umieszczenia tego symbolu zamknięcia, czy nie, gdy ścieżka url jest równa pustemu ciągowi (jak wielu z nas powiedziałoby, gdy URL odnosi się do katalogu głównego witryny). Nikt nie ma prawa do nakładania na ciebie kar „za dwa ujęcia strony głównej”, ponieważ zgodnie ze specyfikacją w obu przypadkach łączysz adres URL z tym samym zasobem.

Kontynuuj z innym fragmentem tego samego akapitu.

Składnia ścieżki url zależy od używanego schematu. Składnia ścieżki url zależy od użytego schematu, a także od sposobu jego interpretacji.

Jest to kolejne potwierdzenie, że każdy schemat lokalizatora ma własną koncepcję „hierarchii” i sposobu jej interpretacji.

Hierarchia

Dalsze fragmenty akapitu 3.2.4 Hierarchia (hierarchia).

Dla każdego zgłoszenia możesz go użyć. Nie oznacza to, że URL jest nazwą uniksową. Symbol „/” służy do wskazania hierarchicznej struktury adresu URL, odpowiednio, do separatora używanego do konstruowania hierarchii nazw plików, a zatem nazwa pliku w niektórych systemach plików wygląda podobnie do ścieżki adresu URL. Ale to nie znaczy, że adres URL jest nazwą uniksową.

Pomimo tego, że ten paragraf odnosi się do schematu ftp, jego oświadczenia mogą być rozszerzone na inne schematy (http, gopher, prospero itp.). Tylko w schemacie pliku ukośnik symbolicznie oznacza to samo, co w nazwach plików, na przykład plik: //server_or_device/path/subpath/filename.txt.

Http

Dalsze fragmenty akapitu 3.3. HTTP .

Adres URL HTTP ma postać: http: // <host>: <port> / <ścieżka>? <Część wyszukiwania> gdzie <host> i <port> są takie, jak opisano w sekcji 3.1. Jeśli pominięto: <port>, port ma wartość domyślną 80. Nie jest dozwolona żadna nazwa użytkownika ani hasło. <ścieżka> jest selektorem HTTP, a <searchpart> jest łańcuchem zapytań. &lt;path> jest opcjonalny, podobnie jak <searchpart> i jego poprzedzające „?”. Jeśli nie występuje <ścieżka> ani <część badawcza>, można pominąć także „/”. W <path> i <searchpart> komponentach „/”, „;”, „?” są zastrzeżone. Znak może być użyty do wyznaczenia struktury hierarchicznej. Adres URL schematu http ma postać: http: // <host>: <port> / <ścieżka>? <Część wyszukiwania> gdzie <host> i <port> są takie same, jak opisano w pkt 3.1. Jeśli pominięto: <port>, zakłada się, że domyślny port wynosi 80. Nazwa użytkownika lub hasło są nieprawidłowe. <ścieżka> jest selektorem HTTP, a <searchpart> jest łańcuchem zapytań. &lt;ścieżka> jest opcjonalna, podobnie jak <searchpart> wraz z poprzedzającym znakiem „?”. Jeśli nie występuje <ścieżka> ani <część badawcza>, znak „/” może zostać pominięty. W elementach <path> i <searchpart> znaki „/”, „;”, „?” są zastrzeżone. Symbol „/” może być użyty w HTTP do zdefiniowania struktury hierarchicznej.

Uwaga Podaje tutaj również, że można określić łącze bez początkowego ukośnika. W tym przypadku była to sytuacja, w której ścieżka łącza jest pusta - wskazuje ona katalog główny hosta.

Formalny zapis

Wreszcie fragment z akapitu. 5. BNF dla określonych schematów URL (formalny wpis dla konkretnych schematów URL).

W nawiasach podano części opcjonalne. Gwiazdka przed nawiasem oznacza 0 lub więcej powtórzeń takiego fragmentu, jak wskazano w nawiasach. Pionowy pasek należy rozumieć jako OR.

hostport = host [":" port] ... ... httpurl = "http: //" hostport ["/" hpath ["?" szukaj]] hpath = hsegment * ["/" hsegment] hsegment = * [uchar | „;” | „:” | „@” | „&” | "="] search = * [uchar | „;” | „:” | „@” | „&” | "="] ... ... lowalpha = "a" | „b” | „c” | „d” | „e” | „f” | „g” | „h” | „i” | „j” | „k” | „l” | „m” | „n” | „o” | „p” | „q” | „r” | „s” | „t” | „u” | „v” | „w” | „x” | „y” | "z" hialpha = "A" | „B” | „C” | „D” | „E” | „F” | „G” | „H” | „I” | „J” | „K” | „L” | „M” | „N” | „O” | „P” | „Q” | „R” | „S” | „T” | „U” | „V” | „W” | „X” | „Y” | „Z” alfa = lowalpha | hialpha digit = "0" | „1” | „2” | „3” | „4” | „5” | „6” | „7” | „8” | „9” safe = „$” | „-” | „_” | „.” | „+” extra = „!” | „*” | „” „ „(„ | ”)” | „,” hex = cyfra | „A” | „B” | „C” | „D” | „E” | „F” | „a” | „b” | „c” | „d” | „e” | "f" escape = "%" hex hex bez rezerwacji = alpha | cyfra | bezpieczny | extra uchar = bez zastrzeżeń | uciec

Zwróć uwagę, jak dokładnie element hpath jest tworzony przez reguły - ścieżkę do łącza. Elementy ścieżki segmentu - segmenty - są oddzielone ukośnikiem. Jakby sugerowanie ważnej idei, że cięcie dzieli ścieżkę na części hierarchiczne i jest zawsze wewnątrz. Zasadniczo nie jest wykluczone, że ostatni element segmentu może być pustym łańcuchem (wynika to z jego definicji), a następnie na końcu adresu URL ukazuje się ukośnik końcowy.

Wniosek

Dzielenie ścieżki na segmenty za pomocą znaku ukośnika oznacza obecność niepustych nazw tych segmentów. W związku z tym łącze z ukośnikiem na końcu wydaje się nielogiczne (choć nie jest zabronione) w tym sensie, że wydaje się wskazywać na pewien ostatni segment ścieżki, ale ponadto nie nazywa tego segmentu. Podobnie link http://domain.com/level1////levelX, który nie nazywa pośrednich segmentów ścieżki, jest nielogiczny (ale również nie jest zabroniony), jeśli ścieżka nie jest traktowana jako zestaw parametrów, ale jako struktura hierarchiczna.

Mówiąc prostym językiem, treść semantyczna dwóch odniesień może być wyjaśniona w następujący sposób:

• http://domain.com/level1/level2 - adresy do domyślnego punktu początkowego drugiego poziomu hierarchii
• http://domain.com/level1/level2/ - adresy do nieokreślonego punktu na drugim poziomie hierarchii, to znaczy tak, jakby serwer przypisywał zadanie, które „uzyskujemy dostęp do drugiego poziomu hierarchii, a ty sam decydujesz, który punkt myślisz domyślny poziom początkowy ”.

Pomimo końcowego ukośnika w drugim łączu, nadal odnosi się do drugiego poziomu hierarchii, a nie trzeciego, ponieważ łącze nie nazwało jawnie nazwy trzeciego poziomu.

Z powyższego wynika, że w taki sam sposób jak linki

• http://domain.com
• http://domain.com/

podaj adres odwiedzającego do katalogu głównego witryny i na przykład linki

• http://domain.com/level1/level2
• http://domain.com/level1/level2/

zaadresuj gościa do drugiego poziomu hierarchii zasobów. A fakt, że serwer może na swój sposób interpretować ukośnik na końcu i zacząć przekierowywać wewnętrznie do domyślnego punktu początkowego poziomu - powiedzmy pliku index.html, jest szczególnym przypadkiem określonej konfiguracji. Podobnie jak w przypadku implementacji czytelnego dla człowieka systemu URL, wszystkie wpisy przekierowania z wykorzystaniem modułu serwera mod_rewrite definiują ich (specyficzną dla silnika) koncepcję hierarchicznej struktury adresu URL, w której elementy ścieżki można zrównać z parametrami żądania i nie mają żadnego połączenia ze strukturą pliku witryny ( klasyczny przykład: http://domain.com/ru/path, ru jest parametrem bieżącego języka, a nie folderem na stronie).

Podkreślam, że jest to wewnętrzna wiedza o serwerze, ze względu na jego konfigurację, a także silnik zainstalowany na stronie. Usługa zewnętrzna, powiedzmy tę samą wyszukiwarkę, nie może robić żadnych przypuszczeń i nie ma pojęcia, czy linki są różne z ukośnikiem lub bez niego, chyba że serwer witryny jest specjalnie skonfigurowany tak, aby takie linki mogły tworzyć inną treść.

Dla twojej informacji

Na poziomie wdrożenia kwestia cięć na końcach nie ma znaczenia, co potwierdza wiele znanych portali. Na niektórych wszystkie linki kończą się ukośnikiem na innych - bez ukośnika. Najważniejsze jest to, że zawartość linków nie okazuje się inna, a dla Yandex musisz zarejestrować przekierowanie 301st z tych linków, których nie używasz (powiedzmy, kończąc ukośnikiem), do tych, których używasz. Faktem jest, że zgodnie z niepotwierdzonymi twierdzeniami usługi wsparcia Yandex ta wyszukiwarka może rzekomo być błędna, a nie „kleić” (pamiętaj o tym w swojej wiedzy) lub, z pewnym opóźnieniem, przykleić adresy ukośnika bez ukośników do jednego.

Oto przykład implementacji takiego przekierowania przy użyciu głównego pliku .htaccess:

# jeśli wejściowy adres URL kończy się ukośnikiem (eat, am), # ustaw przekierowanie 301 na stronę bez ukośnika RewriteCond% {REQUEST_URI} ^ /. + / $ RewriteRule ^ (. *?) / + $ http: //% {HTTP_HOST } / 1 $ [R = 301, L, QSA]

Google (znowu zgodnie z , nie potwierdzone eksperymentem, te przekierowania nie są ważne, jak gdyby wiedział, jak prawidłowo przykleić takie adresy i bez przekierowań.

Pamiętaj, że sporo osób uważa się za specjalistów SEO. Ale nie każdy z nich jest. Co więcej, temat SEO jest często spekulowany bez odpowiedniej wiedzy i rozumu, po prostu licząc na to, że jesteś ignorantem w tej dziedzinie, więc możesz łatwo uwierzyć w każdy „makaron”. Gdy dowiesz się, że część twojej strony „wyleciała z indeksu”, skorzystaj z bardzo dobrej rekomendacji Yandex: Dowiedz się więcej o błędach indeksowania jeśli tak, możesz skorzystać z usługi Yandex.Webmaster. W tej usłudze zawsze możesz zobaczyć listę swoich stron. w wyszukiwaniu i listę stron z jakiegoś powodu wykluczone z wyszukiwania . Google ma podobną usługę. Zaufaj tej wiedzy, a nie opinii pseudo-specjalistów, którzy słyszeli coś z boku uszu i dlatego zalecają, aby robić to, co ich zdaniem jest jedyną słuszną rzeczą.

Co jeszcze można przeczytać na temat SEO

Oto bardzo ciekawa publikacja Niewiele znanych faktów SEO , wydany w kwietniu 2017 roku. Prezentuje obszerne studium z dużą ilością zrzutów ekranu, które rozpoczęło się w celu zweryfikowania ważności kilku popularnych ocen w dziedzinie promocji wyszukiwarek i wykorzystania jasnych przykładów do przekazania wyników zwykłemu właścicielowi witryny. To samo badanie przekazuje młodemu czytelnikowi wiele oczywistych, przyziemnych, a nawet niepozornych, ale wciąż zaskakujących cech produktów ekologicznych w poszukiwaniu Google i Yandex.

Tutaj, choć poniższy link prawie nie dotyczy SEO, nadal będzie atrakcyjny dla seo-mistrzów, którzy teraz szukają dodatkowych zamówień. Pod linkiem znajduje się oferta handlowa, chłopaki znaleźli ciekawy sposób korzystania z witryny. Oferowane są prywatne firmy tworzenie billboardów online na podstawie jakiegoś specjalnego tematu, pod którym strona jest zarządzana, a raczej jej pierwszy ekran wygląda jak baner reklamowy na billboardach reklamy zewnętrznej. Na smartfonie obrócił ekran, rozciąganie stało się pionowe i zajmowało cały obszar ekranu, odwrócone, stało się poziome i ponownie na całym ekranie. A pod pierwszym ekranem znajduje się dodatek tekstowy, w którym użytkownicy zazwyczaj się nie przewijają, ale wyszukiwarka dobrze widzi ten tekst. Tak więc najbardziej zwinna regionalna firma Pinokio kupuje te niedrogie billboardy online jako opłacalną alternatywę dla reklamy kontekstowej i sieci reklamowej Yandex i Google. A żeby maksymalnie wykorzystać czas w lokalnym indeksie wyszukiwania, są gotowi do zarobienia pieniędzy na kilka tekstów seo, aby promować swój billboard, który pachnie jak nie kwasowa ilość. Według plotek, zamówienia na 30 kilobanków prześlizgują się, a ponieważ faceci zlecają seoshnikov swoim partnerom, tutaj można budować mosty partnerstwa i uzyskać dobry profit.