Przejdź do treści
SEO

Jak nie dopuścić serwera origin do indeksu Google

Keeping Your Origin Server Out of Google's Index
W tym artykule
  1. Dlaczego Google indeksuje IP originu albo host stagingowy?
  2. Jak sprawdzić, czy serwer origin jest zaindeksowany
  3. Zablokuj bezpośredni dostęp po IP i ogranicz origin do proxy
  4. Ustawienie hosta kanonicznego za proxy
  5. Usuwanie adresów originu, które Google już zaindeksował
  6. Podsumowanie: naprawa krok po kroku
  7. FAQ

Twój serwer origin pojawił się w indeksie Google? Naprawa ma dwie części. Zamknij origin tak, żeby dało się do niego wejść tylko przez proxy, i skieruj wszystkie sygnały kanoniczne na domenę publiczną, żeby Google scalił wszystko pod tym jednym hostem. Zwykle wygląda to tak: strona stoi za reverse proxy, a mimo to w wynikach wyskakuje surowy adres IP originu (albo jakiś zapomniany przez wszystkich host stagingowy) jako pełna kopia prawdziwej strony. Poniżej: skąd się to bierze, jak to potwierdzić, jak zablokować bezpośredni dostęp, które sygnały kanoniczne naprawdę się liczą i jak posprzątać adresy, które już są w indeksie.

Dlaczego Google indeksuje IP originu albo host stagingowy?

Google zaindeksuje każdy adres, który serwuje Twoje strony jako zwykłą, poprawną odpowiedź. Jeśli więc origin odpowiada na zapytania kierowane na goły IP albo na stary hostname, masz drugą kopię swojej strony. Tyle. A przyczyny są prawie zawsze banalne:

  • domyślny vhost serwera WWW, który serwuje główną stronę bez względu na nagłówek Host,
  • subdomeny stagingowe otwarte na oścież, bez hasła i bez listy dozwolonych IP,
  • linki, mapy witryny albo feedy, przez które wyciekł surowy adres IP,
  • stare rekordy DNS, które nadal wskazują prosto na origin.

W efekcie dostajesz zduplikowaną treść pod IP originu. Konkuruje ona z Twoją domeną kanoniczną i zjada czas indeksowania. Google w wskazówkach o scalaniu zduplikowanych adresów pisze, że lepiej, gdy Googlebot poświęca czas nowym lub zaktualizowanym stronom niż duplikatom. Słusznie. Jest jednak też cichszy koszt, moim zdaniem gorszy: zaindeksowany origin zdradza dokładnie ten adres, który proxy miało ukryć. Staje się też jednym z sygnałów łączących strony ze sobą.

Jak sprawdzić, czy serwer origin jest zaindeksowany

Wyszukaj w Google z operatorem site: IP originu i swoje hosty stagingowe, a potem sprawdź, co origin odsyła, gdy ktoś wejdzie na niego bezpośrednio. Idź w tej kolejności:

  1. Wyszukaj przez site: goły IP i każdy host stagingowy albo stary hostname, jaki przyjdzie Ci do głowy.
  2. Odpytaj IP originu curlem dwa razy: raz bez nagłówka Host, raz z produkcyjnym hostname.
  3. Otwórz Search Console i poszukaj hostów, których nie rozpoznajesz, oraz zduplikowanych stron, dla których Google wybrał inny adres kanoniczny niż Ty.
  4. Przejrzyj mapy witryny, feedy i linki wewnętrzne pod kątem surowych IP albo adresów stagingowych.

Liczą się odpowiedzi. Załóżmy, że bezpośrednie zapytanie na IP zwraca poprawną stronę z pełną treścią. Wtedy origin serwuje Twoją stronę publicznie, a Google może ją zaindeksować równie łatwo, jak Ty ją pobrałeś. Żadnej magii.

Zablokuj bezpośredni dostęp po IP i ogranicz origin do proxy

Najpewniejsza naprawa to origin, który odrzuca każde zapytanie nieprzychodzące przez proxy. Wtedy nie zostaje nic publicznego, co Google mógłby zaindeksować. Na serwerze, którym zarządzasz sam, zwykle oznacza to:

  • Reguły firewalla, które przepuszczają ruch HTTP i HTTPS tylko z adresów IP Twojego proxy.
  • Blok NGINX default_server, który zamyka lub odrzuca zapytania o nieznane hosty i gołe IP.
  • Osobne bloki server_name tylko dla Twoich prawdziwych domen, żeby żaden hostname nie wpadał na główną stronę.
  • Hasło albo listę dozwolonych IP na każdym środowisku stagingowym. Na każdym. To, o którym zapomnisz, będzie tym, które trafi do indeksu.

Odrzucanie bezpośrednich połączeń z originem to zwykła kontrola dostępu. Serwowanie robotom czegoś innego niż to, co widzą ludzie w domenie publicznej, to cloaking i nigdy nie jest dopuszczalnym rozwiązaniem (nieważne, jak kusząco wygląda o drugiej w nocy). Warstwa proxy przed hostingiem, z adresami IP w UE albo w USA, oddziela adres publiczny od originu, a konfiguracja samego originu zostaje w Twoich rękach. Samo proxy nie naprawi jednak dziurawej konfiguracji. Warto wiedzieć, kiedy proxy ukrywa problemy zamiast je rozwiązywać.

Ustawienie hosta kanonicznego za proxy

Za proxy każdy sygnał wysyłany przez origin musi wskazywać domenę publiczną jako host kanoniczny. Dlaczego? Bo origin często nie ma pojęcia, jaki hostname wpisał odwiedzający. Umieść rel=canonical w źródle HTML, wskazując publiczny adres HTTPS, i upewnij się, że żaden JavaScript go potem nie nadpisuje. Dokumentacja Google o kanonikalizacji mówi, że nagłówek HTTP Link z rel=canonical też działa, także dla plików innych niż HTML, na przykład PDF.

Ustaw aplikację tak, żeby budowała bezwzględne adresy URL z nagłówków przekazujących host i protokół, które wysyła Twoje proxy. Dzięki temu adresy kanoniczne, mapy witryny i linki wewnętrzne nigdy nie zawierają IP. Linki wewnętrzne wskazują wyłącznie adresy kanoniczne. Stałe przekierowania na zduplikowanym hoście? Tylko wtedy, gdy wycofujesz ten host. I unikaj błędnych certyfikatów TLS oraz przekierowań z HTTPS na HTTP, bo jedno i drugie mocno pcha Google w stronę wersji HTTP. Certyfikaty też potrafią zdradzić Twoją konfigurację, więc przy okazji przejrzyj ślady zostawiane przez SSL i CDN.

Usuwanie adresów originu, które Google już zaindeksował

Żeby Google usunął zaindeksowane adresy originu, musi móc je odwiedzić i zobaczyć sygnał noindex albo przekierowanie na domenę kanoniczną. Robots.txt to tu złe narzędzie. Wiele osób sięga po nie w pierwszej kolejności, ale dokumentacja Google o blokowaniu indeksowania wyjaśnia, że zablokowane adresy mogą i tak trafić do indeksu, tylko bez treści. Masz dwie opcje, które naprawdę działają:

  • Opcja A: tymczasowo wysyłaj nagłówek X-Robots-Tag noindex w każdej odpowiedzi z originu lub hosta stagingowego, a gdy adresy wypadną z indeksu, odetnij dostęp.
  • Opcja B: jeśli hostname originu musi pozostać dostępny, przekieruj go na stałe na domenę publiczną.

Gdy sprawa jest pilna, narzędzie Google do usuwania adresów szybko ukryje URL-e. Ale tylko na jakiś czas. To plaster, a nie zamiennik poprawionej konfiguracji serwera.

Podsumowanie: naprawa krok po kroku

Potwierdź wyciek. Ogranicz origin do ruchu z proxy. Ujednolić sygnały kanoniczne. Potem posprzątaj to, co już jest w indeksie. Roboty i ludzie dostają tę samą treść w domenie publicznej; odrzucasz tylko bezpośredni dostęp z pominięciem proxy. Usunięcie serwera origin z wyników wyszukiwania to zadanie dla konfiguracji serwera, a nie dla robots.txt.

FAQ

Czy mogę po prostu zablokować origin w robots.txt?

Nie. Adresy zablokowane w robots.txt mogą i tak trafić do indeksu, tylko bez treści. A Google nie zobaczy noindex na stronach, których nie wolno mu odwiedzać, więc blokada może wręcz dłużej trzymać duplikat w indeksie.

Czy blokowanie bezpośredniego dostępu po IP to cloaking?

Nie. Odrzucanie połączeń, które omijają proxy, to kontrola dostępu i działa tak samo dla każdego odwiedzającego. Cloaking to pokazywanie robotom innej treści niż ludziom pod tym samym adresem URL.

Serwery stagingowe: noindex czy uwierzytelnianie?

Uwierzytelnianie albo lista dozwolonych IP to mocniejszy wybór, bo całkowicie blokuje dostęp robotów. Dopóki istniejące adresy stagingowe są usuwane z indeksu, dodaj do tego noindex.

UdostępnijLinkedInX
Zespół Web Systems

Zespół, który tworzy i utrzymuje Jalvo.

Daj każdej stronie własne IP.

Pierwszą domenę dodasz w kilka minut.

Zacznij teraz

Wybierz, na które pliki cookie się zgadzasz. Niezbędne pliki cookie utrzymują działanie strony i logowania, nie można ich wyłączyć.