Widzialni cares about Your privacy
In order to offer access to a secure, functional and attractive service, we use identifiers sent by your device and may store or read small text files (e.g. cookies) contained on your device. Based on your consent, we will process personal data, such as unique identifiers, information sent by end devices for personalization of advertisements and content, statistical demographic information for traffic measurement, we will also analyze the usefulness of certain solutions of the service, their performance in order to improve user satisfaction - hereinafter: your Data. By clicking "Accept all" you consent to the processing of your data in a broad way, including sharing it with third parties - a list of which can be found in the Privacy Policy. By clicking "Personalize" you can make your choice of settings. By clicking "Necessary only," you refuse to consent to the use of optional settings and the transfer of additional data. You can make changes to your choices at any time by clicking the padlock button in the corner of the page. Regardless of your preference settings on our site, you can also manage your browser`s privacy settings. For more information about data processing, see our Privacy Policy.
Manage preferences
Select the consents of your choice
Necessary
Necessary scripts and data stored on the end device contribute to the security and usability of the website by enabling secure access to basic functions such as site navigation and access to specific areas of the website. The website cannot be properly displayed without this group.
Functionality
This is data used to personalize your use of our website and to remember choices you make while using our website. For example, we may use functional cookies to remember your language preferences or to remember your login information, making it easier for you to use the site.
Analytics
Scripts and data used to collect information to analyze site traffic and how users use the site, how they came to the site, and to create aggregate demographic statistics about users. Analytical cookies and similar technologies allow us to measure the effectiveness of actions taken and content presented.
Marketing
Scope responsible for displaying personalized ads that may be of interest to the user based on browsing history and habits and demographic criteria. Also, third-party files that, in conjunction with files installed while browsing other websites, profile the user, providing him or her with the marketing, advertising and retargeting content deemed most appropriate.
Personalize
Accept choices
Accept all
Ukośnik na końcu adresu URL a stanowisko Google

Ukośnik na końcu adresu URL a stanowisko Google

Czy ukośnik w adresie URL ma znaczenie? Jeśli tak, to czy zawsze? Dlaczego właściwie powinniśmy zwracać na niego uwagę?

John Mueller, rzecznik Google, poruszył temat na Twitterze w kontekście powracających co jakiś czas pytań o to, jak Google traktuje ukośniki w adresach URL. Wyjaśniając podkreśla, że to,w jaki sposób Google radzi sobie z ukośnikami, wynika z tego, jak ukośniki są domyślnie obsługiwane przez serwery.

“Ukośnik po nazwie hosta lub domeny jest bez znaczenia. Można go używać, można go nie używać – jeśli chodzi o adresy URL, rezultat będzie taki sam.”

„Jednak ukośnik w każdym innym miejscu jest ważnym elementem URL, a jego obecność lub brak sprawia, że jest to inny adres.”

Zilustruję to wykorzystując przykład Johna:

  A. http://www.example.com/

  B. http://www.example.com

  C. https://www.ecample.com/

  D. https://www.example.com

  E. https://example.com/

  F. https://example.com/seo

  G. https://example.com/seo/

Ukośniki po nazwie hosta/domeny nie mają znaczenia, są to te same strony, a więc A = B, a C = D.

Różne protokoły lub nazwy hosta mają znaczenie. Gdy pojawiają się rozbieżności, istnieją różne wersje tej samej strony pod różnymi adresami, a więc A ≠ C, a C ≠ E.

Ukośnik po nazwie katalogu/pliku ma znaczenie, obie wersje adresu rozpatrywane są osobno, a więc F ≠ G.

Pierwotne zamierzenie było takie, by ukośnik kończący adres URL komunikował serwerowi jakiego rodzaju zasobu szuka. Adres bez ukośnika odnosi się w takim wypadku do konkretnego pliku, natomiast adres z ukośnikiem do katalogu, w którym wywołany zostanie domyślny plik. Miało to wpływać pozytywnie na szybkość ładowania.

Ukośnik w URL – dobre praktyki

  1. Nie używaj w adresie url ukośnika po nazwie pliku, np. http://www.example.com/seo.html/. W takim wypadku serwer będzie próbował odnaleźć katalog o nazwie ‘seo.html’, co w większości przypadków zakończy się wyświetleniem strony błędu 404, a w innych stworzona zostanie alternatywna ścieżka dojścia do zasobu, która zostanie zaindeksowana jako duplikat obniżający wartość strony.
  2. Używaj ukośnika, gdy linkujesz do strony głównej. Tak jak pisał John, nie robi to większej różnicy (w kontekście np. indeksowania), jednak nawet gdy ukośnik nie jest wyświetlany użytkownikom, adres strony głównej to zawsze “/”, a umieszczenie go na końcu adresu sprawi, że strona załaduje się nieco szybciej.
  3. Używaj ukośnika, gdy linkujesz do katalogu. Jeśli go nie ma, wymuszamy na serwerze zbędne przekierowanie. Każdy taki drobiazg może wpływać negatywnie na szybkość ładowania strony.
  4. Dbaj o spójność linkowania. Zarówno budując linki wewnętrzne strony, jak i dodając hiperłącza w innych miejscach w sieci, używaj zawsze tej samej wersji URL dla każdej podstrony.

Powiązane wpisy

Kursy z marketingu internetowego online!

Zarejestruj się do bezpłatnej platformy.

Dołącz do newslettera i otrzymuj regularną dawkę wiedzy oraz ciekawostek ze świata digital marketingu!

Z naszą pomocą zawsze będziesz na bieżąco – bez spamu!

Poznaj historie, które odmienią Twój biznes

Oglądaj na YouTube!

8
Komentarze
Dodaj własny
  1. 1

    „Dbaj o spójność linkowania. Zarówno budując linki wewnętrzne strony, jak i dodając hiperłącza w innych miejscach w sieci, używaj zawsze tej samej wersji URL dla każdej podstrony.”

    Jak autor odniesie się do zasady „first link count”? Z tego podpunktu można wywnioskować, że dywersyfikacja adresów URL w obrębie domeny nie do końca jest optymalnym rozwiązaniem…a jednak lepiej wykorzystywać „luki” w algorytmie niż ich nie wykorzystywać.

    • 2
      Radosław Wiliński

      W pewnym sensie odpowiedziałeś na własne pytanie – jest to bardziej wykorzystywanie luk w algorytmie niż optymalizacja. Osobiście skłaniam się ku spójnemu linkowaniu, ale masz rację, jeśli komuś bardzo zależy na obejściu „first link count”, to jest to jedyny sposób. Dzięki za komentarz!

  2. 3

    Jednak co myślisz. Czy przy obecnej erze downzisingu przy projektowaniu nowych stron warto, aby stosować adres URL http://www.example.com/seo zamiast http://www.example.com/seo/? Zawsze jest to jakaś oszczędność.

    • 4
      Radosław Wiliński

      Oszczędność marginalna, ale wygląda to bardziej schludnie i dlatego skłaniam się ku krótszej wersji.

  3. 5
    Agnieszka Owczarzak

    Myślę, że to ma szczególnie znaczenie przy kampanii linków sponsorowanych, bo nie dość, że tracimy ruch, to jeszcze link nie kieruje tam, gdzie powinien. Mały szczegół, a jednak ma znaczenie.

  4. 6

    Ten wpis Muellera na teamt / akurat mi jakoś umknął mimo, że chyba go śledzę na Twiterze więc dzięki wielkie za fajny artykuł na ten temat 🙂

  5. 7

    Witam
    Czy w takim razie np. do publikacji naukowych PUBMED, gdy w pasku adresu jest widoczny ukośnik na końcu adresu, lepiej podać linki z tym ukośnikiem?

  6. 8

    404, a w innych stworzona zostanie alternatywna ścieżka dojścia do zasobu, która zostanie zaindeksowana jako duplikat obniżający wartość strony. „Raczej do nie istniejącego zasobu” stworzona zostanie w indexie gugla. PS masz literówkę w linku :ecample

Komentarze są wyłączone.

O blogu

Blog powstał w celu przybliżenia marketingu internetowego w wyszukiwarkach wszystkim zainteresowanym tą tematyką. Będziemy dzielić się tutaj naszą wiedzą oraz nowościami z branży. Życzymy miłej lektury.

Szukaj