Просматривая логи об ошибках сайта наткнулся на повторяющуюся строчку:

[date] [debug] mod_rewrite.c(1643): [client IP] mod_rewrite's internal redirect status: 0/10.

Стал копать почему это происходит. Конечно, натолкнулся и на такое решение проблемы:

It's a debug event, usually okay to ignore unless you have a specific problem you are trying to trace.

но оно меня почему-то не устроило.

Просматривая логи доступа и сравнивая с логами ошибок обнаружил, что ошибку вызывают поисковые роботы, пытаясь проиндексировать то, что для них не предназначено. По итогам было принято решение укротить навязчивые поисковики.

Небольшое отступление.

Модуль mod_rewrite.c - это модуль веб-сервера для преобразований URL. Ошибка, описанная выше, может случиться из-за некорректно прописанных правил преобразования URL-адресов в файле .htaccess в корне сайта (или директории на сайте).

Данный модуль представляет собой основанный на правилах механизм (синтаксический анализатор с применением регулярных выражений), выполняющий URL преобразования на лету. Модуль поддерживает неограниченное количество правил и связанных с каждым правилом условий, реализуя действительно гибкий и мощный механизм управления URL. URL преобразования могут использовать разные источники данных, например переменные сервера, переменные окружения, HTTP заголовки, время и даже запросы к внешним базам данных в разных форматах, — для получения URL нужного вам вида.

Этот модуль оперирует с полными URL (включая path-info) и в контексте сервера (httpd.conf) и в контексте каталога (.htaccess) и даже может генерировать части строки запроса в качестве результата. Преобразованный результат может приводить к внутренней обработке, внешнему перенаправлению запроса или даже к прохождению через внутренний прокси модуль.

(http://www.egoroff.spb.ru/portfolio/apache/mod_rewrite.html)

В сайтостроении и борьбе с поисковыми машинами я абсолютный новичок, поэтому, как обычно в таких ситуациях, обратился к Оракулу. Выяснилось, что для решения проблемы нужно грамотно прописать специальный файлик robots.txt, что и было немедленно сделано.

Прописывание файла robots.txt имело целью не дать поисковикам пытаться заходить туда, куда их не просют, то есть не нарываться на запрещающие правила в .htaccess

На основе предложенных вариантов:

<>User-agent: *
<>Disallow: /cgi-bin
<>Disallow: /wp-admin
<>Disallow: /wp-includes
<>Disallow: /wp-content/plugins
<>Disallow: /wp-content/cache
<>Disallow: /wp-content/themes
<>Disallow: /trackback
<>Disallow: /feed
<>Disallow: /comments
<>Disallow: */trackback
<>Disallow: */feed
<>Disallow: */comments
<>
<>User-agent: Yandex
<>Host: blogproblog.com
<>Disallow: /cgi-bin
<>Disallow: /wp-admin
<>Disallow: /wp-includes
<>Disallow: /wp-content/plugins
<>Disallow: /wp-content/cache
<>Disallow: /wp-content/themes
<>Disallow: /trackback
<>Disallow: /feed
<>Disallow: /comments
<>Disallow: */trackback
<>Disallow: */feed
<>Disallow: */comments
<>

<>User-agent: *
<> 
<>Disallow: /wp-content/
<>Disallow: /trackback/
<>Disallow: /wp-admin/
<>Disallow: /feed/
<>Disallow: /archives/
<>Disallow: /sitemap.xml
<>Disallow: /index.php
<>Disallow: /*?
<>Disallow: /*.php$
<>Disallow: /*.js$
<>Disallow: /*.inc$
<>Disallow: /*.css$
<>Disallow: */feed/
<>Disallow: */trackback/
<>Disallow: /page/
<>Disallow: /tag/
<>Disallow: /category/
<> 
<>User-agent: Googlebot-Image
<>Disallow: /wp-includes/
<>

был написан свой и воткнут в корень сайта.

Будем смотреть.

Ссылки

http://blogproblog.com/wordpress_robots_txt/
http://kimochi.ru/wp/ideal-robotstxt-for-wordpress/

Формат Robots.txt (http://www.webcorp.ru/page/format_robots.html)