B\u0142\u0105d soft 404 pojawia si\u0119, gdy adres URL zwraca 200 OK, ale jego tre\u015b\u0107 wygl\u0105da jak komunikat o b\u0142\u0119dzie, pusta strona albo brakuj\u0105cy zas\u00f3b. Google traktuje tak\u0105 stron\u0119 jak nieistniej\u0105c\u0105 i nie dodaje jej do indeksu. Widzisz takie adresy w Search Console i podejrzewasz, \u017ce Tw\u00f3j serwer \u017ar\u00f3d\u0142owy (albo stoj\u0105ce przed nim proxy) serwuje strony b\u0142\u0119d\u00f3w z kodem sukcesu? Z tego poradnika dowiesz si\u0119, jak Google je klasyfikuje, sk\u0105d zwykle si\u0119 bior\u0105, jak potwierdzi\u0107 prawdziwy kod odpowiedzi i jak naprawi\u0107 go na serwerze \u017ar\u00f3d\u0142owym.<\/p>\n\n\n\n
Search Console oznacza stron\u0119 jako soft 404, gdy serwer zwraca kod sukcesu, a sama strona wygl\u0105da jak b\u0142\u0105d, pusta strona albo komunikat o b\u0142\u0119dzie. Kr\u00f3tkie przypomnienie: kod statusu<\/strong> to liczba, kt\u00f3r\u0105 serwer wysy\u0142a przed tre\u015bci\u0105 strony, a roboty odczytuj\u0105 go, zanim w og\u00f3le dotr\u0105 do zawarto\u015bci. Wed\u0142ug przewodnika Google po kodach statusu HTTP<\/a> odpowied\u017a 200 trafia dalej do procesu indeksowania, ale to nie znaczy, \u017ce strona zostanie zaindeksowana. Serwer m\u00f3wi wi\u0119c „sukces”, a strona m\u00f3wi „brak”. Google wierzy stronie. I j\u0105 usuwa.<\/p>\n\n\n\n Prawdziwy kod 4xx jest jednoznaczny. M\u00f3wi Google, \u017ce tre\u015b\u0107 nie istnieje, i tyle. Strona b\u0142\u0119du serwowana z kodem 200 marnuje crawlowanie i zaciemnia sygna\u0142. Google traktuje wszystkie kody 4xx poza 429 tak samo: zaindeksowane adresy, kt\u00f3re zaczynaj\u0105 zwraca\u0107 4xx, s\u0105 usuwane, nowo odkryte strony 404 nie s\u0105 przetwarzane, a cz\u0119stotliwo\u015b\u0107 ich crawlowania z czasem spada. B\u0142\u0119dy serwera i 429 to inna historia. Sprawiaj\u0105, \u017ce Google na jaki\u015b czas ogranicza crawlowanie i zostawia zaindeksowane adresy w indeksie, cho\u0107 strony, kt\u00f3re ci\u0105gle zwracaj\u0105 b\u0142\u0105d, w ko\u0144cu i tak wypadaj\u0105. Przy porz\u0105dkowaniu takich adres\u00f3w popraw te\u017c linki wewn\u0119trzne, kt\u00f3re do nich prowadz\u0105, i przy okazji zadbaj o opisowy tekst kotwicy link\u00f3w<\/a>.<\/p>\n\n\n\n W praktyce zasada jest wi\u0119c do\u015b\u0107 prosta. 404 lub 410 dla tre\u015bci, kt\u00f3rej ju\u017c nie ma, 5xx dla prawdziwej awarii, 200 tylko dla prawdziwej strony.<\/p>\n\n\n\n Wi\u0119kszo\u015b\u0107 b\u0142\u0119d\u00f3w soft 404 bierze si\u0119 z szablon\u00f3w i stron zast\u0119pczych, kt\u00f3re wy\u015bwietlaj\u0105 komunikat o b\u0142\u0119dzie, ale zostawiaj\u0105 domy\u015blny kod sukcesu. Typowi winowajcy:<\/p>\n\n\n\n Dodatkowa warstwa mi\u0119dzy odwiedzaj\u0105cymi a serwerem mo\u017ce to wszystko ukry\u0107. To jeden z problem\u00f3w, kt\u00f3re proxy potrafi ukry\u0107<\/a>, dop\u00f3ki Search Console w ko\u0144cu go nie zg\u0142osi.<\/p>\n\n\n\n Nie ufaj przegl\u0105darce. Wy\u015blij \u017c\u0105danie bezpo\u015brednio pod adres i odczytaj lini\u0119 statusu. Przyjazna strona b\u0142\u0119du wygl\u0105da tak samo niezale\u017cnie od kodu, z jakim przychodzi, wi\u0119c sprawdzaj warstwa po warstwie:<\/p>\n\n\n\n Logi pomagaj\u0105 te\u017c w wyszukiwaniu b\u0142\u0119d\u00f3w w logach serwera<\/a> na du\u017c\u0105 skal\u0119. Przy okazji por\u00f3wnaj rozmiary odpowiedzi. Du\u017co ma\u0142ych, niemal identycznych odpowiedzi 200? Zwykle oznacza to wsp\u00f3lny szablon b\u0142\u0119du.<\/p>\n\n\n\n Niech serwer wysy\u0142a status zgodny z tre\u015bci\u0105: 404 lub 410 dla brakuj\u0105cych stron, 5xx dla awarii, 200 tylko dla prawdziwej tre\u015bci. W aplikacji ustaw kod w obs\u0142udze „nie znaleziono”, a nie tylko w szablonie, kt\u00f3ry ta obs\u0142uga renderuje (\u0142atwo to przeoczy\u0107 i to bardzo cz\u0119sty b\u0142\u0105d). Puste strony wyszukiwania lub list powinny albo zwraca\u0107 404, albo dosta\u0107 prawdziw\u0105 tre\u015b\u0107.<\/p>\n\n\n\n W NGINX u\u017cywaj Stare domeny odbudowane z tekstem zast\u0119pczym albo pustymi szablonami to cz\u0119ste \u017ar\u00f3d\u0142o soft 404 przy ubogiej tre\u015bci. Dla adres\u00f3w z histori\u0105 masz dwie opcje: przywr\u00f3ci\u0107 warto\u015bciow\u0105 tre\u015b\u0107 albo pozwoli\u0107 im zwraca\u0107 404 lub 410. Nie zostawiaj natomiast pustych pow\u0142ok. Planowanie op\u0142aca si\u0119 przy odbudowie stron na starych domenach<\/a>, bo ka\u017cdy adres wymaga jasnej decyzji.<\/p>\n\n\n\n Serwisy, kt\u00f3re potrzebuj\u0105 obecno\u015bci w konkretnym regionie, mog\u0105 te\u017c dzia\u0142a\u0107 za reverse proxy z adresami IP z UE<\/a> lub z USA, a kody statusu nadal zostaj\u0105 pod Twoj\u0105 kontrol\u0105 na serwerze \u017ar\u00f3d\u0142owym.<\/p>\n\n\n\nDlaczego strona b\u0142\u0119du z kodem 200 szkodzi bardziej ni\u017c prawdziwe 404<\/h2>\n\n\n\n
Najcz\u0119stsze \u017ar\u00f3d\u0142a b\u0142\u0119d\u00f3w soft 404<\/h2>\n\n\n\n
\n
Jak sprawdzi\u0107, jaki kod statusu naprawd\u0119 zwraca strona<\/h2>\n\n\n\n
\n
curl -I<\/code> lub curl -sS -o \/dev\/null -w '%{http_code}'<\/code> na oznaczonym adresie.<\/li>\nJak naprawi\u0107 b\u0142\u0119dy soft 404 na serwerze \u017ar\u00f3d\u0142owym i w NGINX<\/h2>\n\n\n\n
error_page 404 \/404.html;<\/code> bez nadpisania =200<\/code> i upewnij si\u0119, \u017ce try_files<\/code> ko\u0144czy si\u0119 na =404<\/code>, zamiast przepisywa\u0107 ka\u017cd\u0105 nieznan\u0105 \u015bcie\u017ck\u0119 na index.php lub index.html z kodem sukcesu. Tre\u015bci usuni\u0119te celowo powinny zwraca\u0107 410. Przekierowanie ma sens tylko wtedy, gdy strona docelowa jest naprawd\u0119 odpowiednikiem. Aplikacje jednostronicowe? Serwer powinien zwraca\u0107 prawdziwe 404 dla nieznanych \u015bcie\u017cek, a przynajmniej tag noindex, a nie pust\u0105 pow\u0142ok\u0119. Po wdro\u017ceniu kliknij Sprawd\u017a poprawk\u0119 w Search Console i obserwuj raport przez kilka kolejnych crawlowa\u0144.<\/p>\n\n\n\nUbogie i puste strony na odbudowanych lub wygas\u0142ych domenach<\/h2>\n\n\n\n