Jakiś czas temu przy okazji analizy jednej ze stron zauważyłem interesujący problem związany z wielkością liter w adresach URL. Postanowiłem przyjrzeć się temu bliżej, przeanalizowałem kilkanaście innych serwisów, w kilku różnych scenariuszach i doszedłem do niepokojących wniosków, które skłoniły mnie do napisania niniejszego artykułu.
Adresy URL są podstawowym elementem w Internecie, ułatwiają lokalizację zasobów. W strukturze serwisów można zaobserwować różne konwencje URL, począwszy od hxxp://nazwastrony.pl/?p=555) a skończywszy na przyjaznych adresach hxxp://nazwastrony.pl/katalog/nazwa-zasobu.html
Problem dotyczy wielkości liter w URL. W większości stosuje się nazwy pisane z małej litery (cały ciąg małymi literami). Przyjmiemy że naturalnym adresem w strukturze serwisu jest...
hxxp://nazwastrony.pl/katalog/nazwa-zasobu.html
Idąc dalej, załóżmy że na jakimś forum użytkownik podał adres URL w postaci...
hxxp://nazwastrony.pl/katalog/Nazwa-zasobu.html
Ostatnia część adresu rozpoczyna się z dużej litery - podczas przepisywania użytkownik popełnił błąd i nieopatrznie zamiast "n" napisał "N". Wiem, sytuacja niezmiernie rzadka, lecz występuje. Zwykle jeśli chcemy podać jakiś link używamy kopiuj/wklej.
Mamy tutaj do czynienia z dwoma różnymi adresami, gdzie drugi adres URL kieruje do innej podstrony. Przy takim scenariuszu możemy spotkać się z dwoma błędami:
- Błąd duplikowania treści w obrębie domeny - strona będzie wyglądała identycznie, jednakże adres URL kierujący do zasobu będzie inny.
- Błąd 404 Not Found - strona nie istnieje.
Dla zobrazowania problemu wezmę dla przykładu dwie witryny (wybrane losowo z badanej próbki), portal Onet i stronę MaxRoy.
Na pierwszy ogień idzie Onet. Poniższe zrzut reprezentują stan witryny z prawidłowym URL i błędnie wpisanym.
Ewidentnie widzimy tutaj, że strona bez względu na wielkość liter w URL jest identyczna.
Drugi przykład, strona MaxRoy...
W tym przypadku wywołanie zasobu z błędnie wpisanym adresem tj. BLog kończy się komunikatem 404.
Witryny, na których próba dostępu do podstrony kończy się błędem 404 powinny bezwzględnie zrobić przekierowanie 301. A co z pierwszym przypadkiem?
W pierwszym przykładzie jest jedna drobna rzecz, która powinna zmartwić administratora witryny, mianowicie chodzi o brak tagu kanonicznego (rel="canonical"), który zapobiega powielaniu treści poprzez informowanie robota Google, który z zasobów jest ważniejszy (który należy traktować jako nadrzędny). Zatem w tym konkretnym przypadku powstaje realny problem powielania treści.
Kwestia jeszcze jak dokładnie Google traktuje podstronę, do której prowadzi kilka, a nawet kilkanaście błędnych URLi duplikujących treść. Czy rzeczywiście mamy tutaj do czynienia z problemem duplicate content?
W toku analizowania całej sytuacji postanowiłem sprawdzić jak Google zareaguje, gdy wpiszę w wyszukiwarce błędny URL. Wybrałem sobie pierwszą lepszą witrynę, która posiada problem duplicate URL.
Na pierwszym zrzucie mamy podstawowy, prawidłowy adres z małym "g", na drugim błędny z dużym "G". Jak widzimy obydwa adresy znajdują się w Google, tym samym zostały zaindeksowane, przetworzone i umieszczone w bazie wyszukiwarki. W obydwu przypadkach wyszukiwarka kieruje na dwa różne adresy z g i G. Możecie zauważyć, iż witryna nie posiada tagu canonical! Więc test potwierdza, że Google rozróżnia adresy, choć w tym przypadku mamy nieco inny wariant - wyszukiwarkę. Sam problem indeksowania wyników wyszukiwania pomijamy w tym artykule.
Trzeba otwarcie powiedzieć, że sama struktura URL w serwisach nie powoduje samoistnego pojawienia się problemu, dlatego nie ma się co dziwić, iż problem zostanie zignorowany przez większość osób, dopóki w narzędziach Google nie pojawi się stosowna sugestia. Lecz co z przypadkowym lub celowym działaniem mającym na celu wymuszenie indeksowania duplikowanego adresu?
Wracając jeszcze do witryny Onetu. Wpisując błędny adres na wyjściu otrzymałem standardowy (właściwy) URL, strona również nie posiada adresów kanonicznych, czy to znaczy, że mamy do czynienia z jakąś anomalią? Czy też witryna Onet jest zabezpieczona przed tym, mimo braku adresu kanonicznego? Wątków śledczych może być wiele, jednym z najbardziej prawdopodobnych jest, iż dana witryna ma zaindeksowaną podstronę widoczną tylko pod jednym (właściwym) URL. Inną możliwością jest, iż Google nie prezentuje duplikatów w wyszukiwarce, a być może cała "zadyma" jest nieuzasadniona?
Aby potwierdzić występowanie problemu należałoby:
- Mieć fizyczny dostęp do Narzędzi dla webmasterów danej witryny, zalogować się i sprawdzić raport HTML, sugestie związane z duplikowaniem tagów lub opisów będą świadczyć o występowaniu problemu.
- Wykonać własne testy w tym zakresie, czyli zaindeksować podstronę, która widoczna byłaby pod dwoma różnymi adresami, z podziałem testów na adresy kanoniczne i bez adresów kanonicznych. Po jakimś czasie sprawdzić w Google Webmaster Tools czy mamy sygnalizację powielania meta tagów.
Na ten moment kompleksowych testów nie wykonywałem (potrzeba na to czasu) więc nie mogę na 100% potwierdzić faktu występowania problemu w pierwszym przypadku - powielania treści. Natomiast punkt drugi, błąd 404 jest już na tyle oczywisty, iż nie wymaga dalszych testów.
Jedno jest pewne, każda witryna z rel="canonical" jest potencjalnie zabezpieczona. Nie zmienia to faktu, iż jeśli chcemy być super dokładni, powinniśmy przekierować użytkownika na właściwą wersję adresu. Jak tego dokonać?
W kolejnym artykule opiszę prostą metodę na przekierowanie nieprawidłowego adresu na podstawowy URL, wykorzystując do tego przekierowanie 301.
Jakie jest Wasze zdanie na ten temat? Czy rzeczywiście mamy tutaj do czynienia z poważnym problemem, czy robię z igły widły?
Zapraszam do komentowania!
Nie ma tutaj żadnego problemu o ile dbamy o to o jednorodną strukturę linków w serwisie. Nikt z zewnątrz nie wpisuje adresu ręcznie typu onet.pl/KoMPutEry, tylko albo kopiuje URL ze strony, albo domyślnie wpisuje go małymi literami. Podobnie sprawa wygląda z linkowaniem wewnętrznym.
Chyba nie zrozumiałeś istoty problemu, mowa tutaj o przypadkowym lub celowym indeksowaniu linków.
Mariusz, z tego co widzę korzystasz z wtyczki Subscribe To Comments która domyślnie ma zaznaczonego 'ptaka'. Możesz powiedzieć jak to zrobiłeś ?. W ustawieniach wtyczki nie mogę znaleźć opcji za to odpowiedzialnej.
Ustawienia => Subscribe to Comments => Formularz komentarzy => Domyślne zaznaczenie => Tak
a wiem w czym był problem, masz zainstalowaną wtyczkę Subscribe to Comments Reloaded a ja Subscribe To Comments.
Anoż, nie używam wersji podstawowej tylko rozszerzoną Reloaded - być może zapomniałem o tym wspomnieć niegdyś
Moim zdaniem zdecydowanie lepiej wygląda z małej litery. Przynajmniej mnie jako copywritera rażą momentami wielkie litery.
Pozdrawiam
Jestem pewien że żaden hosting windowsowy nie wywali w takim przypadku błędu 404.
CO do wszystkich linux-owych to wydaje mi się że jakiś ciekawszy serwer DNS obsłuży takie coś.
NO ALE GOOGLE?
To faktycznie może być duży problem przy pozycjonowaniu (oczywiście w przypadku przypadkowych błędów)
Dzięki za zwrócenie uwagi na problem.
A co ma do tego DNS jak problem występuje na stronie już po procesie translacji adresu IP serwera na domenowy?
Masz rację. Zainicjowanie strony nie stanowi problemu dla serwerów DNS.
W takim razie, jeśli chciał bym się zabezpieczyć przed takim czymś, to mam próbować uodparniac stronę, czy szukac takiej opcji w serwerach WWW.
Sprawdzałem Windowsowe IIS-y nie mają tego problemu (znaczy 404), indeksowanie to inna sprawa.
Nie zdawałem sobie z tego sprawy jak dużo sklepów ma z tym problem