Обнаружил, что при загрузке одной из страниц сайта в фоновом режиме загружается также и главная страница сайта.
Чаще всего такое бывает, когда на странице запрашивается несуществующее изображение, а сайт настроен так, что при запросе несуществующего изображения выполняется редирект на главную. Но это не мой случай (у меня редиректится на 404 - специально перепроверил).

Отключил в браузере изображения - всё нормально (главная в фоне не загружается). Значит, проблема связана с изображениями. Проверил ссылки всех изображений в исходном коде страницы - все ссылки корректные (пустых нет, ни одна из них на главную не ссылается).

Далее полез в отладчик Chrom'а и столкнулся с непонятным явлением. Среди всех подзапросов, выполняемых в ходе загрузки страницы, имеется запрос главной страницы сайта:
авторAccept:image/webp,*/*;q=0.8
Accept-Encoding:gzip, deflate, sdch
Accept-Language:ru-RU,ru;q=0.8,en-US;q=0.6,en;q=0.4
Cache-Control:no-cache
Connection:keep-alive
Cookie: ...
Host:www.site.ru
Pragma:no-cache
Referer: http://www.site.ru/
User-Agent: ...
Как видно, запрашивает "image/webp". Ответ, естественно, получает в "text/html".
При этом в исходном html-коде Chrome указывает на строку, где прописывается javasript:



Одновременно с этим, в консоли выводит сообщение:
авторResource interpreted as Image but transferred with MIME type text/html
-------------------
Здесь всё логично (запрашивает "image/webp", получает "text/html"), кроме главного: с какого перепугу объявление скрипта "text/javascript" в html-коде приводит к попытке загрузке хрен знает какого изображения типа "image/webp" по адресу www.site.ru ?

Ещё одно наблюдение. Если этот проблемный скрипт вообще убрать из кода страницы, то то же самое поведение наблюдается уже на другом (следующем) скрипте. Т.е. проблема не в каком-то конкретном встроенном скрипте, а в присутствии в html любого объявления скрипта.

Загрузка главной страницы в фоне наблюдается в FF и в Chome. В других браузерах не проверял.

авторИмхо, лучше бы не редиректить, а сразу отдавать код 404
Я имел ввиду внутренний редирект.

автори самую минимальную статическую страницу или вовсе без таковой.
Насчёт минималки - да, согласен. У меня сейчас всё, что несуществует - приводит к 404 с определённым объёмом информации
Нужно будет сделать следующее:
1) Для несуществующих изображений нужно будет отдавать минимальный 404
2) Для прочих запросов для ботов - минималку 404, для пользователей - стандартную 404

авторЭто полный список заголовков?Да, это полный список заголовков, отправляемых Хромом при выполнении проблемного фонового запроса

General
Remote Address:xxx.xxx.xxx.xxx:80 (АДРЕС ВЕБ-СЕРВЕРА)
Request URL: http://www.site.ru/
Request Method:GET
Status Code:200 OK

Response Headers
Cache-Control:no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Connection:Keep-Alive
Content-Encoding:gzip
Content-Type:text/html; charset=UTF-8
Date:Tue, 12 May 2015 11:35:49 GMT
Expires:Thu, 19 Nov 1981 08:52:00 GMT
Keep-Alive:timeout=15, max=98
Pragma:no-cache
Server:Apache/2.2.16 (Debian)
Transfer-Encoding:chunked
Vary:Accept-Encoding
X-Powered-By:PHP/5.3.3-7+squeeze19

Request Headers
Accept:image/webp,*/*;q=0.8
Accept-Encoding:gzip, deflate, sdch
Accept-Language:ru-RU,ru;q=0.8,en-US;q=0.6,en;q=0.4
Cache-Control:no-cache
Connection:keep-alive
Cookie:...
Host:www.site.ru
Pragma:no-cache
Referer: http://www.site.ru/
User-Agent:Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.135 Safari/537.36

А вот переменная $_SERVER в момент выполнения на сервере паразитного запроса главной страницы:


Здесь запрашивается "image/png".

Напомню, что при выборе запроса главной страницы (www.site.ru) в списке сопутствующих запросов хром выделяет вот этот код:

авторИ FF тоже image/webp запрашивает?Как видно из дампа переменной $_SERVER, FF запршивает "image/png"

авторДругих вариантов кроме какого-то плагина/дополнения к браузеру что-то в голову не приходит.А человеческий фактор ? А глюки отладчика Chrome ? Исключаем ?

Проблема решена. В html-коде присутствовал встроенный css-стиль с правилом "background-image: URL()"

Отрицательную роль сыграли 2 фактора:
1. Человеческий фактор. Теги src всех изображений в html просмотрел, а "background-image" во встроенных css - нет.
2. Глюки отладчика Chome. Как оказалось для некоторых фоновых запросов (в составе основного запроса) Chome указывал на левые строки в исходном коде, в которых якобы инициировались фоновые запросы. В частности, для сабжевого фонового запроса главной страницы вместо строки с "background-image: URL()" ошибочно указывал на строку с описанием встроенного скрипта. Подобные глюки наблюдались и с идентификацией строки-инициатора для некоторых изображений.

авторА почему думаете, что это глюк? Может процедура рендеринга страницы у него именно такова, что изображение ему требуется именно в момент обработки встроенного скрипта. Маловероятно, поскольку встроенный скрипт меняет 2 класса у элементов страницы. "background-image: URL()" прописан изображению, которое никак не связано с этими элементами (у которых меняются классы). Они в разных частях страницы находятся и в разных блоках (и эти блоки имеют один уровень, т.е. один в другой не вложены). При этом часть изображений загружаются до выполнения этого скрипта, часть - после.

Хотя, этим можно было бы объяснить вот это:
авторЕщё одно наблюдение. Если этот проблемный скрипт вообще убрать из кода страницы, то то же самое поведение наблюдается уже на другом (следующем) скрипте. Т.е. проблема не в каком-то конкретном встроенном скрипте, а в присутствии в html любого объявления скрипта.Впрочем, в последний раз Chrome в качестве строки-инициатора для фоновой загрузки главной страницы сайта указал не строку скрипта, а строку с левой ссылкой (не имеющей отношения в изображению с "background-image: URL()").
Плюс, для некоторых других изображений Chrome тоже некорректно строку-источник определяет (указывает на строку с левой ссылкой)

Так что, 8:2 в пользу глюка.