robots.txt w WordPressie - CybMeta

  1. WordPress robots.txt
  2. Wspólne, ale delikatne zalecenia
  3. Zmodyfikuj robots.txt w WordPress

Plik robots.txt i zawarte w nim instrukcje są implementacją tzw. Protokołu wykluczania robotów ( Protokół wykluczania robotów ).

Przez długi czas widziałem, jak plik robots.txt był używany do celów SEO pod przekonaniem, że blokowanie śledzenia niektórych plików i katalogów może poprawić pozycjonowanie w wyszukiwarkach, a nawet, że robots.txt może blokować złośliwe roboty.

Korzyści SEO, niektóre, ale w szczególnych przypadkach. A jeśli chodzi o blokowanie robotów, robots.txt niczego nie blokuje.

WordPress robots.txt

Jak napisałem kilka dni temu na WPSE , można powiedzieć, że najlepszym robots.txt dla WordPress w ogóle jest właśnie robots.txt generowany przez WordPress . Jego domyślną zawartością jest z WordPress 4.4 i na razie (4.9.8):

User-agent: * Disallow: / wp-admin / Allow: /wp-admin/admin-ajax.php

W większości przypadków nie musisz zwracać uwagi na ten plik. Domyślnie robots.txt jest już dobry:

Wspólne, ale delikatne zalecenia

1. Zablokuj zawartość wp-wp, wp-includes, css, js, obrazy i inne zasoby

Doświadczenie użytkownika jest wskaźnikiem o znacznej wadze w SEO, a jego interpretacja wymaga, aby roboty indeksujące miały dostęp do wszystkich zasobów strony internetowej, a nie tylko do HTML.

Aby zorientować się, jak ważne jest to, co chcę powiedzieć, Google Search Console ma panel przeznaczony wyłącznie do powiadamiania o stronach, na których znajdują zablokowane zasoby :

Aby zorientować się, jak ważne jest to, co chcę powiedzieć, Google Search Console ma panel przeznaczony wyłącznie do powiadamiania o stronach, na których znajdują zablokowane zasoby :

Rejestracja zablokowanych zasobów w Google Search Console

Spójrz na tekst na grafice na poprzednim obrazie:

Przetwarzanie bez określonych zasobów może wpłynąć na indeksowanie stron internetowych.

Wciąż jednak łatwo znaleźć samouczki w Internecie, w których zaleca się blokowanie śledzenia niektórych rodzajów zasobów w celu poprawy SEO.

Na przykład w programie WordPress często spotyka się zalecenia dotyczące blokowania katalogów wp-includes i wp-content, ale to właśnie te katalogi zawierają zasoby używane w publicznej części sieci.

Jeśli nie wiesz, co robisz i masz jasny i dobrze uzasadniony cel, katalogi te nie powinny być blokowane .

2. Robots.txt nie blokuje żadnego robota

Pomimo swojej nazwy protokół wykluczania robotów niczego nie blokuje . Jeśli możesz uzyskać dostęp do zablokowanego zasobu w robots.txt, każdy robot może to zrobić.

Jeśli naprawdę chcesz zablokować dostęp do zasobu, będziesz musiał pracować z innymi narzędziami.

robots.txt zawiera wskazówki , niektóre roboty podążają za nimi, inne roboty nie. Na przykład roboty z Google, Bing i innych wyszukiwarek zwracają uwagę na te wskazówki i nie śledzą ani nie indeksują elementów, które nie zezwalają na robots.txt .

Ale jasne jest, że robots.txt nie blokuje niczego w ścisłym tego słowa znaczeniu, chodzi o to, że oprogramowanie robota chce ignorować, czy nie, tak proste. Blokowanie spamerów, niebezpiecznych lub złośliwych robotów za pomocą robots.txt nie ma dla mnie większego sensu. A jednak jest to również bardzo łatwa rekomendacja do znalezienia w Internecie.

3. Śledzenie blokowania nie zawsze jest najlepszą opcją SEO

Jak wspomniano, roboty z głównych wyszukiwarek przestrzegają wskazówek podanych w pliku robots.txt. Jeśli powiemy mu, żeby czegoś nie czołgał, nie śledzi go, a zatem nie indeksuje.

Ale przez większość czasu, z punktu widzenia SEO, naprawdę chcemy śledzić, ale nie indeksować . Pomyśl o tym trochę.

Podajmy przykład, który bardzo wyraźnie widzę w jednym z najbardziej popularnych zaleceń dotyczących SEO, WordPress i robots.txt: blokuj śledzenie kanałów, tagów, załączników itp. Jednak znacznie lepiej jest pozwolić wyszukiwarkom śledzić te strony, czytać te dokumenty i śledzić linki, które mogą zawierać w innych częściach sieci.

Z robots.txt zapobiegasz indeksowaniu i indeksowaniu. Aby umożliwić śledzenie, ale nie indeksowanie, co jest interesujące, znacznie lepiej jest użyć następujących nagłówków noindex Nagłówki HTTP X-Robots-Tag lub metatagi :

add_action ('template_redirect', function () {if (is_feed ()) {header („X-Robots-Tag: follow, noindex”);}});

Używając tych nagłówków, boty mogą czytać te dokumenty, nawet jeśli nie są indeksowane , a gdy je czytają, mogą śledzić zawarte w nich linki , zwiększając możliwość odkrycia całej zawartości witryny i śledzenia jej zawartości .

Ta metoda może być użyta dla dowolnego zasobu, którego używamy w interfejsie, ale którego indeksowanie nie jest bardzo aktualne.

Na przykład jest on używany w adresach URL interfejsu API WP REST oraz w adresach URL interfejsu API AJAX (wp-admin / admin-ajax.php). Oba są adresami URL używanymi w interfejsie i dlatego powinny być dozwolone do indeksowania, nie powinny być blokowane w robots.txt , chociaż ich indeksowanie nie jest aktualne i jest udostępniane wyszukiwarkom za pomocą nagłówków lub tagów HTTP cel

Konkretny przypadek adresu URL admin-ajax.php jest bardzo dobrym przykładem. Zwróć uwagę, że w domyślnym robots.txt programu WordPress został dozwolony wyjątek w katalogu wp-admin, ale jeśli przetestujesz i przeanalizujesz nagłówki HTTP, znajdziesz nagłówek X-Robots-Tag: noindex.

Katalog wp-admin został zablokowany w robots.txt w całości do wersji 4.4 WordPress, Joost de Valk (Yoast.com) zasugerował umieszczenie pliku admin-ajax.php jako wyjątku , ponieważ był często używany w interfejsie przez wiele wtyczek i blokowany w błędach generowanych przez robots.txt w Google Search Console. Dlatego powinno być możliwe śledzenie, ale nie indeksowanie.

Zmodyfikuj robots.txt w WordPress

Mimo wszystko nadal istnieje wiele sytuacji, w których modyfikacja robots.txt WordPressa jest w pełni uzasadniona , chociaż nie jest to ściśle związane z SEO, a tym bardziej ze względów bezpieczeństwa.

WordPress tworzy plik robots.txt w locie , plik robots.txt tak naprawdę nie istnieje fizycznie, a do zmodyfikowania robots.txt konieczne jest wykonanie z PHP z filtr robots_txt ,

Na przykład, wyobraź sobie, że chcesz zablokować indeksowanie katalogu cgi-bin, katalogu określonej wtyczki i dodać odwołanie do mapy witryny :

add_filter ('robots_txt', funkcja ($ output) {$ output. = "Disallow: / cgi-bin / n"; $ output. = "Disallow: / wp-content / plugins / plugin-what-I-want-block / n "; $ output. =" Sitemap: ". site_url ('sitemap.xml')." "n"; zwraca $ output;});

Spowoduje to powstanie następującego pliku robots.txt (domyślna treść plus ta dodana w kodzie):

User-agent: * Disallow: / wp-admin / Allow: /wp-admin/admin-ajax.php Disallow: / cgi-bin / Disallow: / wp-content / plugins / plugin-what-I-want-block / Sitemap: https://example.com/sitemap.xml

Możesz także zablokować cały folder wtyczek, ale zezwalaj na pliki .css i .js, dodając te wiersze:

User-agent: * Disallow: / wp-content / plugins / plugin-to-block / Allow: /wp-content/plugins/plugin-a-block/*.css Zezwól: / wp-content / plugins / plugin-a -block / *. js

Te zmiany w pliku robots.txt można również wykonać, tworząc plik robots.txt i przesyłając go na serwer, a nie przez filtr robots_txt, ale po utworzeniu pliku zablokujesz korzystanie z robots.txt przez WordPress i dowolną wtyczkę, która używać

Na przykład większość wtyczek tworzących mapy witryn dodaje jeden lub więcej wpisów do robots.txt przy użyciu interfejsu API WordPress. Jeśli plik robots.txt naprawdę istnieje, nie mogą tego zrobić.

Pamiętaj więc, że w WordPressie nie powinieneś tworzyć pliku robots.txt bezpośrednio na serwerze , powinieneś pracować przez API WordPress.

Referencje