Jak wyszukiwarka traktuje linki w obrębie własnej domeny

Warto najpierw ustalić punkt odniesienia, bo dyskusja o bezpieczeństwie często odbywa się bez niego.

Zasady dotyczące spamu linkowego opisują sytuacje, w których ktoś próbuje sztucznie zdobyć lub sprzedać sygnały z obcych witryn — kupione wpisy, wymiany, farmy. Odnośniki wewnątrz jednej domeny mieszczą się w kategorii decyzji nawigacyjnych właściciela serwisu. To on ustala, co uznaje za ważne i co z czym łączy.

Przedstawiciele wyszukiwarki od lat powtarzają tę samą myśl w różnych wariantach: linkowanie wewnętrzne to narzędzie w rękach właściciela strony i wypada z niego korzystać. Nie ma tam żadnego limitu ani zalecanej liczby odnośników w tekście.

Z tego wynika praktyczny wniosek. Nie szukam odpowiedzi na pytanie „czy to jest dozwolone”, bo jest. Szukam odpowiedzi na pytanie, czy po wdrożeniu serwis jest łatwiejszy do zrozumienia dla robota i wygodniejszy dla czytelnika, czy trudniejszy w obu wymiarach.

Cztery scenariusze, w których automat pogorszył sytuację

Wszystkie widziałem na żywo, żaden nie jest hipotezą.

• Reguła słowo–adres bez limitów. Ktoś ustawił, że każde wystąpienie danej frazy w serwisie zamienia się w odnośnik do podstrony ofertowej. Po dwóch latach ta fraza była podlinkowana kilkanaście tysięcy razy, w tym po pięć razy w jednym artykule, czasem w dwóch kolejnych zdaniach.

• Odnośniki do stron, które przestały istnieć. Reguły przetrwały przebudowę serwisu, docelowe adresy nie. Automat produkował więc linki prowadzące do przekierowań albo wprost do błędów, w tysiącach kopii.

• Wzajemne zapętlenie. Dwa teksty linkowały do siebie w obie strony, a moduł „powiązane” dokładał do tego jeszcze pięć adresów z tej samej grupy. Efekt: zamknięta kieszeń, z której trudno wyjść zarówno robotowi, jak i człowiekowi.

• Podmiana kontekstu. Reguła podlinkowała frazę w zdaniu, które mówiło coś dokładnie odwrotnego niż strona docelowa — na przykład w akapicie wyjaśniającym, czego dana usługa nie obejmuje.

Żaden z tych przypadków nie skończył się filtrem ani ręczną karą. Wszystkie skończyły się serwisem, w którym linkowanie przestało nieść jakąkolwiek informację, bo wszystko było podlinkowane wszędzie.

Odnośniki dostawiane w przeglądarce

Osobna kategoria, o której trzeba mówić wprost, bo tutaj ryzyko techniczne jest realne.

Wyszukiwarka renderuje strony, więc odnośniki dołożone JavaScriptem zwykle zostaną znalezione. Kluczowe słowo to „zwykle”. Renderowanie odbywa się z opóźnieniem i nie zawsze w pełnym zakresie. Jeśli cała warstwa linkowania powstaje po stronie klienta, uzależniasz strukturę serwisu od procesu, na który nie masz wpływu i którego nie widzisz w logach serwera.

Dochodzą do tego wymogi formalne. Link musi być znacznikiem z atrybutem podającym adres. Element reagujący na zdarzenie kliknięcia, który przenosi użytkownika skryptem, dla robota nie jest odnośnikiem — i przy takim wdrożeniu można mieć setki połączeń, których wyszukiwarka nigdy nie zobaczy.

Sprawdzam to zawsze tak samo: podglądam wyrenderowany kod w narzędziu do sprawdzania adresu URL w Search Console i porównuję z tym, co widzę w przeglądarce. Jeśli różnica jest duża, przenoszę generowanie na stronę serwera, nawet jeśli oznacza to więcej pracy programisty.

Kiedy szkoda dotyka czytelnika, nie robota

Ten aspekt wypada z dyskusji najczęściej, a decyduje o tym, czy ktoś w ogóle wróci na stronę.

Tekst z odnośnikiem w co drugim zdaniu jest po prostu trudny do przeczytania. Wzrok zatrzymuje się na każdym wyróżnieniu, a jeśli połowa z nich prowadzi w miejsca bez związku z pytaniem czytelnika, buduje się nieufność do całego serwisu. Na telefonie dochodzi jeszcze jedno: gęsto rozstawione odnośniki w akapicie są trudne do trafienia palcem i część kliknięć jest przypadkowa.

Widzę też odwrotne przegięcie — moduły „polecane dla ciebie” tak duże, że wypychają treść poniżej ekranu. To już nie kwestia linkowania, a rozkładu strony, ale w projektach automatyzacji jedno i drugie zwykle wdraża ta sama osoba w tym samym tygodniu.

Mam na to jedną prostą regułę: jeśli po wdrożeniu sam nie chcę czytać własnego artykułu, wracam do ustawień. Wskaźniki tego nie wychwycą wystarczająco szybko.

Skala, budżet indeksowania i szablon

Przy dużych serwisach dochodzi wymiar czysto ilościowy.

Każdy dodany odnośnik to kolejna ścieżka, którą robot może pójść. Jeśli automat linkuje do adresów z parametrami, wyników filtrowania czy paginacji, potrafi w krótkim czasie wygenerować mnóstwo nowych, bezwartościowych tras w serwisie. Przy sklepie z filtrami to najkrótsza droga do sytuacji, w której roboty spędzają większość czasu na kombinacjach, których nikt nie szukał.

Druga rzecz to umiejscowienie. Odnośniki wstawione w powtarzalnych elementach szablonu, obecne na każdej podstronie, mają dla wyszukiwarki inne znaczenie niż te wplecione w treść. Nie znaczy, że są bezużyteczne — nawigacja jest potrzebna. Znaczy, że nie należy liczyć na to, że tysiąc identycznych odnośników w stopce zastąpi kilka sensownych połączeń w tekście.

Dlatego przy audycie takich wdrożeń zawsze rozdzielam linki szablonowe od kontekstowych i liczę je osobno. Bez tego rozdziału raport pokazuje setki tysięcy połączeń i nie mówi zupełnie nic.

Jak to testuję i jak się z tego wycofuję

Automatyzację wdrażam wyłącznie wtedy, gdy potrafię ją wyłączyć jednym ruchem i wiem, co dokładnie zmieniła.

Zaczynam od jednej sekcji serwisu, nie od całości. Zanim ruszę, zapisuję pełny stan wyjściowy: crawl z listą wszystkich połączeń, żeby po miesiącu móc porównać. Po wdrożeniu robię crawl ponownie i sprawdzam trzy liczby: ile odnośników przypada na tekst w najgorszym przypadku, ile adresów docelowych zbiera nieproporcjonalnie dużo połączeń i ile linków prowadzi do przekierowań lub błędów.

Ustawiam też twarde ograniczenia w samej regule — maksymalnie kilka odnośników na artykuł, tylko jedno wystąpienie danej frazy w obrębie tekstu, wyłącznie adresy z listy dopuszczonych. Reguła bez limitu górnego jest w mojej ocenie głównym źródłem wszystkich opisanych wcześniej awarii.

Na koniec wpisuję do kalendarza przegląd co kwartał. Skrypt działa dalej, kiedy strona się zmienia, i tylko regularne zaglądanie do wyniku wyłapuje moment, w którym zaczął pracować przeciwko serwisowi.

Odpowiedź, której zwykle udzielam

„W pełni bezpieczne” to sformułowanie, którego nie użyję o żadnym rozwiązaniu wdrożonym w kilkudziesięciu tysiącach miejsc naraz.

Uważam natomiast, że automatyzacja z limitami, z listą dopuszczonych adresów docelowych, generowana po stronie serwera i przeglądana raz na kwartał jest wyraźnie bezpieczniejsza niż stan, który zastaję na większości dużych portali — czyli brak jakiejkolwiek struktury i przypadkowe odnośniki dodawane przez dwudziestu redaktorów według dwudziestu różnych intuicji.

Ryzyko rośnie liniowo z zakresem swobody, którą oddasz skryptowi, i z czasem od ostatniego przeglądu. Te dwie zmienne masz pod kontrolą i o nich warto rozmawiać, a nie o karach, których w tym obszarze nie ma.