Skaner zepsutych linków wewnętrznych

Jak działa ta kontrola

Scanaris zbiera wszystkie linki <a href> z HTML-u Twojej strony i zostawia wewnętrzne: te, które rozwiązują się do tego samego źródła (domena, protokół i port). Odrzuca mailto:, tel:, javascript:, kotwice zaczynające się od #, linki do samej strony i duplikaty, i ogranicza listę do 25, żeby nie zasypywać Twojego serwera. Odwiedza każdy i liczy go jako zepsuty tylko wtedy, gdy odpowiada 404, 410 lub błędem 5xx. Przekierowania nie są błędem, 401 ani 403 też nie (to może być celowo prywatna strefa), a jeśli żądanie zawiedzie na poziomie sieci, nie jest liczone, żeby nie dawać fałszywych alarmów. Przy trzech lub więcej zepsutych linkach ustalenie ma średnią wagę; przy jednym lub dwóch niską. Wymienia do dziesięciu z ich kodem.

Dlaczego to ważne

Zepsuty link to ślepa uliczka dla użytkownika i dla Google. Dla użytkownika strona błędu tam, gdzie spodziewał się produktu, artykułu albo formularza, i powód, żeby wyjść. Dla Google zmarnowany budżet indeksowania i sygnał zaniedbanej witryny; w dodatku autorytet, który ten link przekazywał stronie docelowej, przepada. Zepsute linki na stronie głównej są najgorsze, bo to najczęściej skanowana strona i ta, którą widzi najwięcej ludzi, i dlatego ta kontrola zaczyna właśnie tam.

Dlaczego tak się dzieje

Strony, które zmieniły nazwę lub zostały usunięte bez aktualizacji menu i treści, które do nich linkowały. Migracje CMS-a lub domeny zmieniające strukturę adresów. Linki wpisane ręcznie z literówką. Wdrożenie, które usunęło ścieżkę, do której stopka nadal linkowała. A na stronach generowanych przez AI linki do stron, które AI wymyśliła w menu („/pricing", „/docs") i które nigdy nie powstały.

Jak to naprawić

• Jeśli strona się przeniosła, przekierowanie 301 ze starego adresu na nowy. Tak naprawiasz za jednym zamachem wszystkie linki, które tam wskazywały, łącznie z tymi z innych witryn. W Nuxt routeRules; w Next.js redirects(); na Vercel i Netlify plik przekierowań; w WordPressie wtyczka do przekierowań.
• Jeśli strona już nie istnieje i nie ma zamiennika, usuń link. Jeśli chcesz, żeby Google szybko o niej zapomniało, odpowiadaj 410 zamiast 404.
• Jeśli to literówka, popraw href. Frameworki z typowanymi ścieżkami (Nuxt z typedPages, Next.js z typedRoutes) zamieniają te błędy w błędy kompilacji.
• Błędy 5xx to nie źle wpisane linki, tylko strony, które nie ładują się poprawnie. Sprawdź logi tej ścieżki: zwykle to zapytanie, które się wywala, albo zasób, którego już nie ma.
• Dodaj sprawdzanie linków do CI (lychee, linkinator), żeby następna zepsuta ścieżka nie trafiła na produkcję.

Sprawdź, czy naprawione

curl -s https://twojadomena.pl | grep -oE 'href="/[^"#]*"' | cut -d'"' -f2 | sort -u | while read p; do
  printf "%s " "$(curl -s -o /dev/null -w '%{http_code}' "https://twojadomena.pl$p")"; echo "$p"
done | grep -E "^(404|410|5)"

Nie powinna pojawić się żadna linia. Powtórz na najważniejszych stronach oprócz głównej: każda strona ma własne linki.

Często zadawane pytania

Moja strona to SPA i nieistniejące ścieżki zwracają 200 z aplikacją.

W takim razie ta kontrola nie może wykryć Twoich zepsutych linków, bo wszystko odpowiada 200. Ale Google wykrywa je jako „soft 404" i traktuje jako błędy. Skonfiguruj serwer lub framework tak, żeby nieznane ścieżki odpowiadały prawdziwym 404.

A linki do innych witryn?

Nie są sprawdzane: wiele witryn blokuje boty i dawałoby fałszywe alarmy. Sprawdzaj je sam od czasu do czasu narzędziem desktopowym albo sprawdzaniem w CI, które możesz skonfigurować, żeby odwiedzało je cierpliwiej.

Mam tylko jeden zepsuty link i jest niskiej wagi. Naprawiać?

Tak: to minuta, a następny skan to potwierdzi. Innych pozostałości po rozwoju, które zwykle towarzyszą zepsutemu linkowi, jak adresy do localhost, szuka odniesienia wewnętrzne; a czy Google ma właściwą listę Twoich stron, sprawdza robots i mapa witryny.