nash, прагму, наверное, сам сервер, или CMS-ка ставит. Но с ней надо разбираться во вторую очередь. А в первую -- с Last-Modified:
Вот еще неплохая статья: http://xpoint.ru/know-how/Articles/SlezhenieZaKontentom
И еще вдобавок: если Вы формировали Last-Modified: как Вами указано выше, то для корректного кеширования такой код неприемлем, т.к. он при каждом обращении будет отдавать новое значение, гарантированно не совпадающее со значением, имеющемся в кеше броузера, и броузер каждый раз будет вынужден, вместо того, чтобы брать страницу из кэша, тянуть ее с сервера.
Что мы видим:
HTTP/1.1 200 OK Date: Mon, 06 Nov 2006 22:36:50 GMT Server: Apache/1.3.37 (Unix) mod_ssl/2.8.28 OpenSSL/0.9.7a PHP/4.4.4 mod_perl/1.29 FrontPage/5.0.2.2510 X-Powered-By: PHP/4.4.4 Set-Cookie: ns=adac9d61b2bd1ed2062b768f30d09781; path=/ Expires: Mon, 06 Nov 2006 23:03:31 GMT Cache-Control: max-age=1600 Pragma: no-cache Connection: close Content-Type: text/html
1) Хотя "Pragma: no-cache" для HTTP 1.1 и неактуален, но лучше его убрать.
2) "Last-Modified:" все-таки нужен, без него никак (причины уже SunDrop объяснил)
Ссылку покажите
nash, проверьте еще заголовок Last-Modified:
Предпочтительный формат даты должен соответствовать не "пониманию" Яндекса, а стандарту (RFC 1123, со ссылкой на RFC 822). Там указано, что timezone можно указывать в буквенном, или числовом формате. Например: "GMT" (Universal Time), или +0400 (Local differential hours+min).
Таким образом, их совместное использование некорректно. Для Last-Modified я использую, и рекомендую использовать, формат такого вида:
Mon, 06 Nov 2006 07:35:28 GMT
Никаких коллизий при этом нигде не возникало.
P.S. Для интересующихся: все варианты определения timezome
zone = "UT" / "GMT" ; Universal Time ; North American : UT / "EST" / "EDT" ; Eastern: - 5/ - 4 / "CST" / "CDT" ; Central: - 6/ - 5 / "MST" / "MDT" ; Mountain: - 7/ - 6 / "PST" / "PDT" ; Pacific: - 8/ - 7 / 1ALPHA ; Military: Z = UT; ; A:-1; (J not used) ; M:-12; N:+1; Y:+12 / ( ("+" / "-") 4DIGIT ) ; Local differential ; hours+min. (HHMM)
У меня есть четыре сайта, где сделана динамическая навигация в виде меню-"дерева". Естественно, с использованием display:none. И все прекрасно индексируется. И ничего в бан не попадает.
Во-первых, для более точной постановки задачи давайте примем количество "конечных" страниц одинаковым для обоих вариантов.
Во-вторых, результат будет зависеть от того, имеются, или нет "обратные связи" (т.е., ссылки с "конечных" страниц на главную).
Если они есть -- тогда больший вес на "конечные" страницы будет передаваться в варианте 1.
Если их нет -- тогда больший вес на "конечные" страницы будет передаваться в варианте 2.
Хотя разница и в том, и в другом случае будет весьма незначительной. Настолько незначительной, что ею вполне можно будет пренебречь.
Лучше смотреть не с точки зрения Я, а с точки зрения стандартов.
<h...> -- это блочный элемент, а <a href=...> -- инлайновый. Инлайновые элементы никто не запрещает помещать внутрь блочных. Но не наоборот.
Уточняем по справочнику (HTML 4.0 Reference):
Таким образом,
<h2><a href="url">Текст ссылки</a></h2> -- вполне корректно, а
<a href="url"><h2>Текст ссылки</h2></a> -- некорректно
Dixi.
Статистика по одному из моих сайтов (правда, русскоязычному, но ориентированному исключительно на украинскую аудиторию) за сентябрь-октябрь:
google.com 34,60%
yandex.ru 24,20%
meta.ua 11,25%
rambler.ru 6,88%
Год назад соотношение yandex/google было противоположное.
