Czym jest user agent? Jego rola w przeglądarkach i w SEO

User Agent to pojęcie związane z siecią, a konkretniej z jednym z najważniejszych protokołów, który umożliwia wymianę informacji w sieciach, czyli HTTP. Może wydawać się nam, że to działka głównie specjalistów IT albo programistów zajmujących się tzw. backendem czy API. Ale również SEOwcy spotykają się prędzej czy później z tym pojęciem, a to za sprawą jednego z ważniejszych - z punktu widzenia SEO technicznego - konfigurowalnych elementów na stronie, mianowicie pliku robots.txt. 

W tekście przyjrzymy się zagadnieniu User Agentów najpierw z perspektywy technologii informatycznej, a następnie z punktu widzenia SEO, by wszyscy zainteresowani wiedzieli już, co konkretnie jest przedmiotem konfiguracji w pliku z zaleceniami dot. crawlowania.

User-agent jako część nagłówka protokołu HTTP

Szczegóły połączenia poprzez protokół HTTP świadomie pominiemy. Wystarczy informacja, że urządzenie wysyłające żądanie (w terminologii nazywane klientem) załącza tzw. header (nagłówek), czyli szczegóły informujące serwer, jaką akcję zamierzamy względem niego podjąć. Przykładowy header żądania strony głównej Salestube wygląda następująco: 

    GET / HTTP/1.1

    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-   exchange;v=b3;q=0.7

    Accept-Encoding: gzip, deflate, br, zstd

    Accept-Language: pl-PL,pl;q=0.9,en-US;q=0.8,en;q=0.7

    [...]

    Host: salestube.tech

    [...]

    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36

    [...]

W naszym przypadku jest żądanie dostępu do zawartości mieszczącej się pod adresem URL salestube.tech.

1) GET / HTTP/1.1 informuje serwer o metodzie (GET - "przyślij mi") oraz wersji protokołu HTTP używanej do nawiązania połączenia. Inne opcje to chociażby POST ("przesyłam ci..."), DELETE ("usuń ze swoich zasobów...") itd.

2)  Accept, Accept-Encoding oraz Accept-Language to informacje dotyczące formy, w jakiej serwer ma nam wysłać odpowiedź: formacie plików, dopuszczalnych form kompresji tych plików czy języka, w którym są one napisane;

3) Host, czyli nazwa serwisu wg rejestrów DNS i domena, ewentualnie wraz z subdomeną;

4) i finalnie to, co jest przedmiotem naszych dzisiejszych dywagacji. Omówimy go szczegółowo poniżej.

User Agent - szczegóły

Nagłówek user agent dostarcza serwerowi informacje o nazwie urządzenia czy aplikacji, z którymi jest kompatybilny, tj. których można użyć z tym User Agentem, żeby uzyskać daną zawartość. Jest obecny w każdym żądaniu wykonywanym przez protokół HTTP. Ma postać ustandaryzowaną i zawiera szczegóły dotyczące programu. Zazwyczaj zawiera także system operacyjny (Windows, Mac, Linux), wersję czy rozszerzenia. Schemat, wedle którego tworzone są jego wartości, prezentuje się następująco:

User-Agent: <produkt>/<jego wersja><komentarz>

W naszym przykładzie jest to Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36.  Konwencją jest wylistowanie urządzeń od najważniejszych do najmniej istotnych. 

Jakie urządzenia mogą korzystać z user-agentów? Zasadniczo wszystkie, z których możemy wykonać żądanie sieciowe przy użyciu protokołu HTTP - począwszy od przeglądarek internetowych, skończywszy na skryptach wykorzystywanych w terminalach komputerów, jak cURL. 

Przyjrzyjmy się, jak wyglądają te, które są wykorzystywane przez najpopularniejsze przeglądarki. Warto dodać, że user-agenci mogą różnić się też w zależności od systemu, z którego korzystamy. 

Google Chrome

• Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36

Mozilla Firefox

• Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:133.0) Gecko/20100101 Firefox/133.0

Microsoft Edge

• Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36 Edg/131.0.2903.86

Safari

• Mozilla/5.0 (iPhone; CPU iPhone OS 13_5_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.1.1 Mobile/15E148 Safari/604.1

User-agenci a SEO, czyli o konfiguracji robots.txt

Bardzo konkretnym punktem styku na drodze przeciętnego SEOwca oraz User Agentów jest plik robots.txt. Używamy go, aby kontrolować dostęp naszej strony przez konkretne boty, podczas gdy innym tego dostępu zabraniamy. Boty możemy rozpoznać - oraz kontrolować - właśnie po tym, że korzystają z konkretnych user-agentów, którzy są publicznie znani. Na szczęście nie musimy pisać w pliku robots.txt całych długich linii tekstu, wystarczą aliasy.

Przyjrzyjmy się najważniejszym crawlerom, z których korzysta Google.

User-agent: Googlebot

• Token kontrolujący głównych user-agentów: Googlebot Smartphone oraz Googlebot desktop.

User-agent: Googlebot-Image

• Token kontrolujący crawlowanie elementów kwalifikowanych do Google Obrazów, Google Discovery, Google Video i wszelkich rozszerzonych graficznych elementów w klasycznym SERP.

• Jeśli załączamy dyrektywę allow dla "klasycznego" Googlebota, nie musimy konfigurować tej dyrektywy oddzielnie - chyba że nie chcemy dopuszczać crawlowania tym robotem któregoś katalogu naszego serwisu.

User-agent: Googlebot-Video

• Skupia się na wynikach wyszukiwania powiązanych z wideo. W kwestii konfiguracji sytuacja przedstawia się podobnie, jak wyżej.

User-agent: Googlebot-News

• Crawlowanie w celu pokazania w Google Newsach. Ponownie, jak wyżej. 

Jakimi dyrektywami możemy kontrolować roboty?

Crawlery prawidłowo rozpoznają jedynie cztery dyrektywy:

• user-agent: tak właśnie identyfikujemy crawlera, który powinien się do naszych zaleceń dostosować. 

• disallow: pierwsze zalecenie. Brzmi: tu nie wchodź.

• allow: zalecenie drugie, zarazem przeciwieństwo poprzedniego.

• sitemap: identyfikator adresu URL, pod którym znajdziemy sitemapę. Może być ich więcej niż jeden.

Esencją pliku robots.txt jest odpowiednia konfiguracja allow / disallow. Ideą allow jest wskazanie tych katalogów czy sekcji, które robot może odwiedzać - automatycznie od całej reszty jest "odgrodzony". Dissalow z kolei odwrotnie, otwiera przez botem całą stronę, zakazując jedynie wstępu do konkretnych obszarów. Oba mogą również służyć do zablokowania całej strony.

Która z tych dyrektyw umożliwia bardziej elastyczną konfigurację? Jak je łączyć, by uzyskać odpowiednią kombinację? Zobaczmy to na przykładach.

Jak wygląda przykładowa konfiguracja?

Dyrektywy zapisujemy, wypisując ścieżki do folderów. Możemy również posłużyć się czymś w rodzaju uproszczonych wyrażeń regularnych, żeby za cel wziąć konkretne pliki. Ale po kolei.

Przyjrzymy się plikowi umieszczonemu na naszej własnej stronie internetowej - i nieco go zmodyfikujmy, na potrzeby tego ćwiczenia. Wymyślmy też dwa nowe boty: UnwantedCrawler oraz Newsbot. Załóżmy, że tylko one oraz roboty Google crawlują cały internet.

Tak prezentuje się domyśla konfiguracja. Oznacza ona aktualnie, że każdy robot ma dostęp do każdej zawartości.

User-agent: *
Allow: /

Sitemap: https://salestube.tech/sitemap.xml

Przytoczmy kilka scenariuszy, na które możemy napotkać w czasie konfiguracji.

Zablokowanie części / całości strony jednemu z botów

UnwantedCrawler zdecydowanie nie powinien mieć zbyt dużego dostępu do naszej strony. Zakładając, że nie powinien w ogóle odwiedzać naszych artykułów blogowych znajdujących się w katalogu /blog/, do pliku powinniśmy dodać: 

User-agent: unwantedcrawler
Disallow: /blog/

A być może nie chcemy go w ogóle - w takim wypadku całość konfiguracji wyglądałaby tak:

User-agent: *
Allow: /

User-agent: unwantedcrawler
Disallow: /

Sitemap: https://salestube.tech/sitemap.xml

Zablokowanie jednej części strony, odblokowanie innej 

Sytuacja pozornie podobna, ale nieco bardziej skomplikowana. Newsbot jest bowiem przez nas pożądany, ale nie musi crawlować całości. Wszystko, co powinno go interesować, znajduje się w (hipotetycznym) katalogu /news/. Dodajemy więc:

User-agent: *
Allow: /

User-agent: unwantedcrawler
Disallow: /

User-agent: newsbot
Allow: /news/

Sitemap: https://salestube.tech/sitemap.xml

Co więcej, chcemy jeszcze, by miał dostęp do katalogu ze zdjęciami, które wykorzystujemy w newsach. Wtedy:

User-agent: *
Allow: /

User-agent: unwantedcrawler
Disallow: /

User-agent: newsbot
Allow: /news/
Allow: /static/photos/

Sitemap: https://salestube.tech/sitemap.xml

...ale w katalogu ze zdjęciami mamy zdjęcia w dwóch formatach - .jpg oraz .tiff. Te drugie nie powinny naszego bota w ogóle interesować. Możemy więc postawić na bardzo konkretną formułę: 

User-agent: *
Allow: /

User-agent: unwantedcrawler
Disallow: /

User-agent: newsbot
Allow: /news/
Disallow: /static/photos/
Allow: /static/photos/*.jpg$

Sitemap: https://salestube.tech/sitemap.xml

Jak rozumieć to połączenie disallow i allow? Następująco: zablokuj dostęp do /static/photos/ z wyjątkiem adresów URL, które kończą się na ".jpg". Symbol gwiazdki (*) zastępuje dowolny ciąg znaków (w naszym przypadku byłyby to nazwy plików). Symbol dolara ($) wskazuje natomiast, jak musi kończyć się adres URL. Mówiąc prościej: dopóki adres URL znajdujący się w folderze /photos/ kończy się na .jpg - crawluj, resztą się nie zajmuj.

Na koniec dodajmy jeszcze jedną rzecz: żaden z crawlerów nie powinien przejmować się adresami URL z konkretnym parametrem analitycznym. By to osiągnąć, wystarczy do linii odnoszącej się do wszystkich botów dopisać linijkę z konkretnym parametrem. Dla przykładu:

User-agent: *
Allow: /
Disallow: /?srsltid=

Należy przy tym być precyzyjnym, bo znaków zapytania używa też zazwyczaj paginacja, a tę chcemy crawlerom jak najbardziej udostępniać. 

Czy zmiana user-agenta wpływa na wyświetlanie stron internetowych?

Odpowiadając pokrótce, ale bardzo w duchu SEO: to zależy. To wystarczy, aby każdemu SEOwcowi w głowie zapaliła się lampka: czy to oznacza, że odwiedzający jakąś stronę na smartfonie może zobaczyć coś innego niż odwiedzający ją na komputerze osobistym? Czy tak kluczowe elementy jak Page Title, nagłówki czy atrybuty noindex mogą być inne? Jak już mówiliśmy, jest to możliwe technicznie. A jak wygląda to w praktyce? Pora sięgnąć głębiej...

Punktem wyjścia jest konieczność responsywnego designu. Przede wszystkim chodzi o takie ułożenie układu, elementów, rozmiaru czcionek i obrazów, by strona prezentowała się dobrze i była wygodna w obsłudze nie tylko na komputerze, ale także na smartfonach czy innych urządzeniach mobilnych. 

Jedna z koncepcji rozwiązujących ten problem prezentuje się następująco: a może by tak przygotować wersję strony na smartfony oraz oddzielną na komputery osobiste, a następnie przesyłać użytkownikowi odpowiednią stronę w zależności od wartości user-agent? Jak wspomnieliśmy, technicznie nie ma przed tym większych ograniczeń. Jednak powszechnie uważa się to za złą praktykę. Po pierwsze, Google crawluje już niemal wyłącznie wersje mobilne. Po drugie, User-agent mówi wyłącznie o kompatybilności, nie o parametrach urządzeń, z których wysyłane jest żądanie. 

Z tego powodu responsywny design sięga po zupełnie inny zestaw środków. Wersja strony jest jedna, ale jest odpowiednio dostosowana w zależności od rodzaju ekranu czy rozdzielczości. Dba się o to, żeby obrazy i filmy pokazywały się we właściwych proporcjach, bo zmienia się ułożenie i rozmiar elementów, w których zostały w strukturze strony osadzone. Targetowanie user-agentów jest zatem rozwiązaniem o wiele bardziej "sztywnym" i przez to zawodnym. 

Odpowiadając zatem na pytanie z nagłówka: zmiana user-agenta nie zmieni dostępności elementów na danej stronie, a w każdym razie nie powinna. 

Czy mogę sam zmienić user agent (także w kontekście web scrapingu)?

Wspomnieliśmy o różnych wersjach strony w zależności od wartości User-Agenta. Jeśli chcielibyśmy sprawdzić ten parametr, musielibyśmy przełączać się między różnymi user-agentami (przynajmniej wersji desktopowej i mobilnej). Na szczęście możemy to łatwo zrobić w przeglądarce. Poniżej krótka instrukcja dla komputerów:

1. Klikamy prawym przyciskiem myszy na dowolnym obszarze ekranu w przeglądarce internetowej.

2. Pojawi się panel narzędzi deweloperskich. W jego prawym górnym rogu klikamy na ikonkę koła zębatego - czyli w ustawienia.

3. W ustawieniach wybieramy devices i klikamy "Dodaj nowe urządzenie". W okienku możemy wprowadzić dowolny obsługiwany string.

Ręczne przeglądanie każdej podstrony trudno jednak nazwać efektywnym spędzeniem czasu podczas audytu SEO. Na szczęście narzędzia crawlujące, takie jak Screaming Frog, również umożliwiają zmianę takiego agenta. Dzięki temu możemy łatwo, wygodnie i masowo sprawdzić, czy nie występują znaczne odstępstwa między wersją mobilną i desktopową. Pole to znajdziemy w zakładce "User-Agent" w ustawieniach. Dodajmy jednak, że jest to opcja dostępna tylko w wersji licencjonowanej.

Osobny akapit warto poświęcić user-agentom w kontekście web scrapingu. User-agent od Google rzeczywiście może otworzyć przed nami kilka metaforycznych drzwi więcej, ale nie liczmy, że będzie to uniwersalny, magiczny wytrych. Niektóre strony internetowe stosują o wiele bardziej wysublimowane zabezpieczenia przed scrappingiem, takie jak szyfrowanie newralgicznej zawartości (numery telefonów, maile). Mimo wszystko, korzystanie z przeglądarkowych user-agentów, zamiast domyślnych, jest dobrą praktyką.

Pytania i odpowiedzi dotyczące user-agentów

Na koniec skupimy się na kilku pytaniach, które mogły pojawić się w trakcie czytania.

Gdzie mogę sprawdzić mój aktualny user-agent?

W bardzo prosty sposób można zrobić to chociażby w przeglądarce Google. Wystarczy wpisać hasło "what's my user-agent". Dla chętnych i bardziej zaawansowanych - możemy również sprawdzić header naszego dowolnego żądania w zakładce "Network" w narzędziach deweloperskich dowolnej przeglądarki internetowej.

Czy zmiana user-agenta może pomóc w ominięciu blokad regionalnych?

Niestety nie i nigdy nie było to zresztą planowaną częścią implementacji user-agentów. User-Agent nie przesyła bowiem w sobie żadnych danych geolokalizacyjnych. Blokady regionalne działają, bo dostawcy internetu przydzielają naszym routerom adresy IP ściśle powiązane z naszą lokalizacją.

Czy user-agent może być używany do śledzenia mojej aktywności online?

W pewnym sensie tak. Bywają one "przechwytywane" do celów analitycznych oraz do późniejszego rozwiązywania potencjalnych problemów ze stroną. W końcu, jak już wspominaliśmy, niektóre strony blokują dostęp robotom scrapującym na ich podstawie.

User-Agenci nie będą mieli jednak żadnej wartości dla marketerów czy innych analityków ścieżki klienta, ponieważ pojawiają się wyłącznie w nagłówkach żądań protokołu HTTP. Jedyne, czego można dzięki nim dowiedzieć się o nas, to fakt, że korzystaliśmy z urządzenia, które jest kompatybilne z danym user-agentem. Takich urządzeń jest zazwyczaj wiele, zwłaszcza, że większość z nas do przeglądania internetu używa smartfona albo komputera z przeglądarką. Nie ma tu mowy o personalizacji czy śledzeniu ścieżki.