SeoChase

Subscriber

Уже в процессе создания и перед первыми регистрациями сайта в каталогах и главное в поисковиках, возник такой вопрос:

Сайт создается с использованием SSI, т.е. страницы по-сути состоят
из нескольких фрагментов html-кода, которые монтируются на сервере
в единую страницу перед выдачей пользователю-посетителю...

А теперь собственно вопрос: А каким образом с страницами и вообще
сайтами построенными на SSI взаимодействуют спайдеры поисковых систем?

Уточню - они получают страницы для индексации так же и в том же виде что и остальные посетители (т.е. после обработки запроса сервером) или видят всю эту файловую мозаику самостоятельно?... И если это так, то будут ли они находить страницы, если меню сайта (ссылки на разделы, например) находится в таком кусочке...

И вообще - как влияет на индексацию поисковиками такая структура сайта?
_________________
Рассылка "Продвижение сайта. Профессиональные советы экспертов".
http://www.optimization.ru/subscribe/list.html
- - - - - - -
Вопрос в рассылку можно задать, написав письмо на subscribe@ashmanov.com

WebByte

Никак не влияет.
SSI - это не фреймы.
И паук увидит то же, что видит пользователь.
Считайте его обычным пользователем, но с текстовым браузером.

Вот ветка форума Яндекса, где на этот вопрос Садовский ответил.

AiK · Lincoln Зарегистрирован: 12.09.2004 Сообщения: 451

Действительно, если у вас 10 страниц собирается при помощи SSI, то никакой разницы с тем же количеством обыкновенных статических HTML страниц вы не заметите. Если у вас будет 1000 страниц в SSI, которые написаны раз и навсегда, то они будут проиндексированы чуть позже, чем 1000 обычных HTML страниц. А вот если из этой 1000 страниц часть страниц (допустим 100) довольно часто обновляется, то тут будет полное преимущество у обычных HTML страниц - они будут проиндексированы полностью, а вот у некоторой части SSI страниц будут хорошие шансы остаться непроиндексированной. Всё дело в том, что правильно настроенный web-server может обрабатывать заголовок HTTP-запроса If-Modified-Since (см. RFC 2616 раздел 14.25), т.к. для статической HTML страницы определена дата создания (изменения) документа, а для SSI такая дата неопределена. Поэтому, в случае статических страниц, робот поисковика избавлен от необходимости выкачивать с сервера неизменившиеся страницы.

Interitus · Lincoln Зарегистрирован: 24.06.2004 Сообщения: 764

А правильно настроенный сервер - это какой? Который в файлах с расширением .htm/.html не обрабатывает SSI? А если обрабатывает - то сервер не правильно настроен?

AiK · Lincoln Зарегистрирован: 12.09.2004 Сообщения: 451

Алексей, подколоть решил? Smile

Я ж написал: в даном случае правильно настроенный тот сервер, который обрабатывает дерективу If-Modified-Since.

Interitus · Lincoln Зарегистрирован: 24.06.2004 Сообщения: 764

Да какие уж тут подколы...
Ты ведь фигню написал. Smile

RFC утверждает, что:

AiK · Lincoln Зарегистрирован: 12.09.2004 Сообщения: 451

Ага, ну-ка расскажи, как сервер(!) будет выбирать дату для SSI документа. Он тебе по дефолту 200 отдавать всегда будет.

Interitus · Lincoln Зарегистрирован: 24.06.2004 Сообщения: 764

А причем тут по дефолту?
Как настроишь - так и будет выбирать. Если составляющие не изменились, и он будет отдавать 304 - это вполне правильно будет, и неважно, SSI там внутри, или еще какое PHP.

AiK · Lincoln Зарегистрирован: 12.09.2004 Сообщения: 451

Interitus, вот тебе простой пример:
header & footer написаны раз и навсегда, body тоже, но выгребает данные из БД с периодом обновления содержимого от одного дня до полугода. Сервер не имеет никаких шансов узнать обновилось ли содержимое body конкретной страницы c последнего визита бота или нет. Если ты в скрипте не определяешь дату изменения контента и в нём же не обрабатываешь If-Modified-Since, то настройка сервера с общим для всех страниц периодом обновления на мой взгляд пустая трата времени.

Опровергай ход мысли Smile

Interitus · Lincoln Зарегистрирован: 24.06.2004 Сообщения: 764

А чего опровергать, я с этим согласен. Smile

AiK · Lincoln Зарегистрирован: 12.09.2004 Сообщения: 451

А с такой формулировкой согласишься?

Interitus · Lincoln Зарегистрирован: 24.06.2004 Сообщения: 764

И с этой формулировкой соглашусь, т. к. отрицание этого утверждения очевидно неверно. Laughing

Однако верно и следующее:
Правильно настроенный web-server может обрабатывать заголовок HTTP-запроса If-Modified-Since (см. RFC 2616 раздел 14.25) для произвольного GET-запроса, и отдавать 304 в случае, если фактический контент не изменился.

AiK · Lincoln Зарегистрирован: 12.09.2004 Сообщения: 451

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

Interitus · Lincoln Зарегистрирован: 24.06.2004 Сообщения: 764

Допустим, установлен mod_accel, который кеширует страницы, а если в исходном запросе есть if-modified-since - он его режет, передает запрос бекенду, контент сравнивает с закешированным, и если совпадает - отдает клиенту 304.
Это он настроен или запрограммирован?

AiK · Lincoln Зарегистрирован: 12.09.2004 Сообщения: 451

Во-первых, это слабо похоже на настройку, ибо mod_accel не является стандартным. Во-вторых, почитал я доку к mod_accel и узнал, что он сам бэкэнду передаёт запросы с "If-Modified-Since". Т.е. скорее всего не сравнивает кеши, а надеется что бэкенд это за него сделает. Если бэкэнд этого делать не умеет, то всем страницам опять таки будет задан единый для всех период "свежести".
Поправь, если ошибаюсь.