Есть примеры ?

Если в спортивных целях, то дерзай - думай дальше ничего умного сказать не могу, а если в практических, то уже обсуждалось, что на 1-м месте посетителей больше, а клиентов меньше - поищи по топикам.

Всетаки оптимизация не ясна до конца.

Мы берем сайт, грамотно организовываем, прописываем где чего надо в нужных пропорциях, регистрируем где надо. Т.е. все как полагается, поэтапно и рассудительно.

А на первые места не попадает, где конкуренция велика... есть 100% фича у профи оптизаторов, есть!

И пофигу на всякий иц, виц, х*иц.., pr и т.п.

Где правда ?

не факт. конвертация траффика в живые деньги от покупателей от самого сайта зависит уже.

ну вот когда будут все знать не только где надо, но и КАК надо, тогда мы и победим америку, идрёна кочерыжка ☝

romsel, поэкмпериментирую в контентом и тегами - имхо должно помочь.

Ceres, да заманался я эксперементировать, если интересно могу в личку кинуть.. посмотри, мож поможешь чем )

Я денег плачу за обучение!

Упорство, трудолюбие, аккуратность и свои идеи...

А также наличие возможности и умений их полностью реализовывать и получать от этого выгоду :)

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

Про структуру документа мы знаем вот что:

1. Чем меньше кода - тем легче его читать роботам.

2. Чем валидней код - тем легче его читать роботам.

Я стараюсь писать легко и валидно скорее даже из эстетических целей, насколько ощутимо влияние на поисковики судить не могу - эксперементов не ставил.

Чтоб код был легче - предпочтительнее использовать блочную верстку, но это целое искусство. В качестве примера - посмотрите http://www.csszengarden.com/ - к одному и тому же ХТМЛ прикручены разные CSS-файлы и показано, чего можно добиться используя чисто CSS1.

Соответственно, выносим все позиционирования и пр. в отдельный .css, скрипты - .js, и уже лучше. Тщательно анализируем каждый тег на предмет нужности. Стараемся использовать дивы, поскольку и код легче (чтоб обозначить блок - один тег вместо трех <table><tr><td>), и по логике вернее (вообще, таблички разрабатывались именно для того, чтоб делать таблички - календарики, прайсики и т.д., а не для верстки). Еще полезно раза 3 с интервалом в неделю переверстывать все целиком (если конечно есть возможность через 1 шаблон работать со всем сайтом и позволяет время).

Но я в очередной раз повторяю, что перестал почти верить в силу внутренних факторов. Можно месяц просидеть над кодом, высчитывая всякие density и куда-бы еще h1 втиснуть, а тебя обойдет сайт на флеше, у которого ключевики только в титле, зато ссылок вагон и маленькая тележка.

На счет валидности - я тут когда-то спрашивал, сказали, что толку от нее никакого. Не так давно пришлось писать функции разбора чужих документов, и тут-то я почуствовал, насколько трудно парсить документы с ошибками. Быстрее всего обрабатывается валидный XHTML, с просто HTML проблем уже больше, но реализуемо, а вот реализовать 100% адекватный разбор HTML с ошибками (в рамках того бюджета и ресурсов сервера) у меня однозначно не получилось. Просто не представляется возможным учесть все ошибки. Для верстальщика незакрытый тег или там пересечение инлайнового и блочного элементов - фигня, ничего страшного. Правильно, когда документ разбирается на клиенте - не так уж и страшно, но на самом деле - необходимость на каждом последующем шаге разбора проверять возможность неявного закрытия, плюс еще помнить, что тег может быть закрыт явно, но потом, и еще куча проблем, а в конечном итоге - строить предположения, что же хотел сказать верстальщик. И не забываем, что робот яндекса работает на сервере, ему такие проблемы не очень-то улыбаются, и наверно проще принять первое предположение за правду, нежели возиться с кривыми тегами. Таким образом, в кеше может оказаться совсем не то, что предполагалось.

А вообще, красивый легкий код - это по дефолтам хорошо, чего я тут стараюсь-то :)