Даже проверять смысла не было. Валидатор проверяет синтаксис HTML, а не реальное расположение тегов на экране браузера.
А там вмешивается позиционирование.
ТС, не заморачивайтесь, по большей части это всё ерунда для стилевого оформления страницы.
Есть сайт где вообще весь контент помещен в теги H1/2/3 - живет уже много лет и Яндекесу на это по-барабану.
Я делаю все динамические сайты только с БД, не важно сколько страниц.
1. Гибкий поиск по сайту
2. Простота администрирования и управления сайтом (текстом, тайтлами), добавление страниц. Менюшки страниц сайтов собораются сами после добавления разделов в БД.
3. Неограниченный возможности дальнейшего развитися (собственные системы статистики, защиты от скачивания и тп.)
4. Простота и прозрачность кода движка (если он собственного производства)
5. Есть возможность уникализовать текст страниц, по-другому пересобрав их из полей БД
6. Легче использование всяких модных технологий типа Ajax - из базы проще сделать выборки по условиям.
7. Проще делать автоматические внутренние перелинковки по полям из БД.
8. Странийы сайтов на БД генерятся быстрее, чем на файловой системе (кроме готовой статики на html). Mysql вообще может держать нужные таблицы в оперативке.
9. Неограниченные СЕО-возможности от генерации ЧПУ-url с ключевиками, до автоматической генерации анкоров простановки внешних ссылок (например, их специального поля БД KewWords) с подсчетом сколько внешних ссылок установлено и на каких страницах. Все это можно легко хранится в БД.
Если надо чтобы сайт работал на narod.ru - просто делаю выгрузку сайта в виде html и заливаю по фтп.
У сайтов на файловой системе (статике) одно преимущество - Apach сам обрабатывает запросы кеширования на стороне клиента (LastModified).
Но для малостраничных сайтов - это фиолетово.
Имхо, сайты на файловой системе бесперспективны в плане СЕО и сбора трафика (и заработка), тк имеют ограниченное кол-во страниц -> узкое семантическое ядро.
PS: А, да, что такое Битрикс я не знаю, не надо приводить его как пример тормознутости по пункту 8. Сравнивайте уж тогда с генерацией страницы из 1000 разных файлов с поиском в них по регулярке.
Простенькая CMS на БД типа Mysql - это 3 файла из 15, 25 и 89 строк на php и файл шаблона. (не считая панели администрирования).
Все дальнейшие навороты - пишешь модули по конкретным задачам.
Помеха. Вы попробуйте статистику Рамблера попарсить.
Как это скрыт? Без реального IP пакет обратно не прилетит. В логах сайта все IP есть.
Выловить и забанить, если это не прокси местного регионального провайдера. С ними есть проблемы - туча народа ходит с одного IP.
Title не может снизить вес, при неправильном Title снижается релевантность страницы запросу.
Так делает движок сайта, чтобы хоть как-то уникализовать Тайтлы, когда их "в ломы" писать ручками.
С точки зрения СЕО так делать неправильно (кроме цели уникализации тайтлов).
1. Title - не резиновый, Яндекс сейчас учитывает (ну, это смотря для чего учитывает) первые 24 слова (подробности - см экперимент по длину Title Сергея Кошкарева).
2. Ближние к началу Title имеют больший вес (по классической формуле ранжирования).
Имхо, с точки зрения теории Вы правы: заголовок "X-Requested-With" нестандатрный, в rfc2616 на протокол http/1.1 его нет.
RFC 2616 разрешает использовать нестандартные Request-header, если их поддерживают все стороны, участвующие в коммуникации.
В том топике tombrown обнаружил, что 1% пользователей сидят за прокси или проклятыми узлами связи, которые не пропускают "левые" заголовки и "X-Requested-With" в том числе.
На сегодняшний день в стандартах W3 XMLHttpRequest и майкрософт XMLHttpRequest такой заголовок нигде не упоминается, поэтому запросто может и не поддерживаться какими-нибудь прокси или аппаратными фаерволами типа Cisco PIX.
Поэтому, при всем моём уваженнии к LEOnidUKG, Ваше замечание о возможных проблемах весьма уместно.
Этот header ставят jQuery и Prototype, можно поставить любой через setRequestHeader().
Если просто создать объект через ActiveXObject("Msxml2.XMLHTTP"), ActiveXObject("Microsoft.XMLHTTP") или XMLHttpRequest() - этот заголовок не прилетит.
ПрактеГ, посвяти в идею-то.
Юзать реферер - несколько некошерно, тк прокси по дороге могут его и отрезать.
PS: А если я с флешом страничку дёрну - определите?
Только прописать ссылки Ява-скриптом, и то сейчас уже не уверена, что ПС не понимают и не исполняют JS.
Google давно выдирает url из ява-скриптов и ходит по ним.
На сегодня 100% надежый вариант - подгружать ссылки на ajax. Или не забивать голову глупостями и ставить нормальные ссылки. Вся целостность Интернета держится на ссылках.
PS: Тега <nofollow> нет, есть атрибут rel=nofollow для тега <a.
А прикол <noindex> - Яндекс не индексирует содержимое внутри <noindex>, но по ссылкам внутри него - переходит, то есть их видит.
Проще написать php-скрипт, который считает контрольную сумму или проверяет размеры файлов.
И дату последней можификации БД, если нужно.
В случае чего - отправляет SMS или Емайл админу.
Никак. К веб-серверу прилетает обыкновенный POST или GET запрос.
Или передавайте какой-нибудь параметр в url (&ajax), или передавайте ajax-запросы по POST, при условии, что все не-ajax запросы работают по GET.
