Огромное спасибо всем, приславшим предложения. Жена устроена, резюме более не дейтвует.
Interitus, Вы, наверно, правы, я погорячился слегка. Действительно, предполагать, что на просторах инета может откуда-то взяться валидный код, мягко говоря, неразумно, поэтому все обрабатывается по одному алгоритму. Ну и парсить-то поисковикам особо не надо, только title выдрать и контент, грубо говоря. В невалидном коде дерево построить сложно, а им оно и не надо (SAX этого в принципе не делает, как я понимаю). А отделить контент (плюс значимые теги типа h, em, strong, title) от разметки - не так сложно, вне зависимости от валидности кода.
Не понял про рендериг таблиц и дивов. Почему таблицы обрабатываются быстрее? Из-за необходимости подгружать CSS при дивной верстке?
Насчет важности отношения объема кода к объему контента - не совсем уверен. Плотность и близость к началу ведь считается на основе кеша, а там только контент и лежит.
Поиграться с позиционированием руки не доходят. Единственно, ставил как-то менюшку на место через DOM на JS, чтоб она в коде была после текста, а в браузере - где надо. Особой пользы не почувствовал.
Про дивы и резину: делать вариант целиком на CSS не пробовал, все равно приходилось DHTML использовать. Зато через этот самый DHTML можно сверстать гораздо аккуратнее. Основные траблы возникают при оптимизации под браузеры с отключенным JS - там приходится фантазию напрягать.
Flack, очень смело Вы говорите. В некоторых случаях фиксирванный дизайн ничуть не менее юзабелен резины. И всегда юзабельнее плохо выполненной резины, когда на маленьком мониторе слова идут в столбик, а на большом - весь текст в одну строчку. И всегда это зависит от конкретного макета.
Я уже писал на эту тему. С технической точки зрения, чем перегруженнее и невалиднее код, тем сложнее его парсить. Кому хоть раз приходилось писать парсилки, со мной согласится. Проще всего парсить валидный XML - он для этого и создавался. А любой незакрытый тег - это серьезная нагрузка на браузер и на роботов, которые с кодом работают. И восемь вложенных тегов тоже. Чем сложнее код - тем труднее в нем разобраться, а поскольку ресурсы у яндекса не резиновые, а всех ошибок и "загагулин" в коде предусмотреть невозможно, я могу предположить, что при разборе кода могут делаться некоторые "допущения", необходимые для снижения нагрузок на ресурсы. Чем сложнее код - тем более непредсказуемым может оказаться результат такого "допущения". Хотя, это не более чем гипотеза.
Другой вопрос - можно ли на дивах написать более легкий код, чем на таблицах. На первый взгляд конструкция <table><tr><td class="..">...</td></tr></table> втрое сложнее, чем <div class="..">...</div>. Но по собственному опыту - при первой попытке использования дивов вложенность (и вообще число всяческих "загагулин") получилась больше, чем в том же случае на таблицах. За счет того, что таблицы привычнее и там есть наработанные приемы. Так что тут требуется некоторое мастерство.
И очередной раз предлогаю всем изучить код здесь: http://www.csszengarden.com/ с учетом того, какая его часть нужна специально для реализации идеи (которую тоже всем советую изучить).
Всем большое спасибо!
Наверное, понимание придет с опытом) но пока у меня есть ощущение, что предварительное списывание - это дополнительный шаг в процедуре, требующий усилий. Попробую так)
А предположение про конкурентов не выдерживает критики? Еще давно когда-то получил такой веселый ответ, мол, вы че, сбрендели, будем мы вам еще тиц поднимать, когда у нас ключевики одинаковые, а в топе тесно. С тех пор есть некоторые подозрения)))
Да, еще одно предположение.
Возможно именно поэтому не любят ставить ссылку первыми - т.е. они увидели, что их ссылка уже размещена, и думают, что она там на веки и останется, потому что постоянно проверять, не поставили ли они ссылку и писать письма - утомительно (действительно так), а удалять не хочется, потому что остается надежда, что они соизволят ответить взаимностью. Может так?
Не так давно совершенно случайно обнаружил пачку сайтов (портфолио одной конторы), на которых админка лежит в папке /admin/ - логин=admin, пароль... не поверите, =password. Вот и думайте, чего хотите:) а еще спрашивают, где ссылки брать) сижу голову ломаю, совестью мучаюсь: с одной стороны - нехорошо, с другой стороны - это ж фактически FFA! Ну, и сайты, правда, зело заброшенные. Так что не столь уже бесполезна такая система, кое-кому может оказать действенную помощь)
P.S. Не подумайте плохого - просто подруга просила один из сайтов потестить, я разбирался, чего за ПО стоит, оно правда случайно получилось :)
Ребята замечательные. Эти тексты я не читал, меня там еще что-то зацепило. Вообще, много смешного. Сейчас каталогов разных понаплодилось немеряно, и один важнее другого, а тут и подача выгодно отличается, и, кстати, с технической точки зрения все очень правильно, ссылки полезные раздают. Переписывался с ними, помню, очень приятное впечатление произвели. Удачи им!
P.S. (А неверняка ведь где-то здесь ходят %)))))
Попытался повторить с гуглой. Может я чего не так ответил? На 27 вопросе предположила, что это search engine. Долго пытался добиться ответа "гугля", или хотя бы уложиться в 20 вопросов - нифига. Самый максимум - вот так:
Q27. I am guessing that it is a search engine (web site search)?
Right, Wrong, Close
26. Can it add? Partly.
25. Does it have buttons? Partly.
24. Does it play music? No.
23. Does it use electricity? Yes.
22. Can it be used for recreation? Maybe.
21. Is it used by the police? Maybe.
20. I guessed that it was science? Close.
19. Do most people use this daily? Yes.
18. Is it something you bring along? No.
17. I guessed that it was sign language? Wrong.
16. Is it comforting? Yes.
15. Do you know any songs about it? No.
Can it cheer you up? Unknown.
14. Is it pleasurable? Maybe.
13. Do you use it in your home? Yes.
12. Can you get information by using it? Yes.
11. Is it a feeling? No.
10. Do you use it when you write? No.
9. Is it considered valuable? Yes.
8. Does it get wet? No.
7. Can you buy it? No.
6. Does it make noise? No.
Can you play games with it? Unknown.
5. Is it outside? Irrelevant.
4. Is it human powered? Yes.
3. Is it a common household object? No.
2. Is it used for entertainment? Partly.
1. It is classified as Other.
?
Exit
Очень смешная штука, спасибо)
Не, ребята захватят рунет)
Я проснуться толком не успел - а они уже мою ссылку разместили, бэклинка требуют) я вроде и мыл этот нигде не светил) и сайтик захолустный) Так это какие ж у них масштабы!
Про структуру документа мы знаем вот что:
1. Чем меньше кода - тем легче его читать роботам.
2. Чем валидней код - тем легче его читать роботам.
Я стараюсь писать легко и валидно скорее даже из эстетических целей, насколько ощутимо влияние на поисковики судить не могу - эксперементов не ставил.
Чтоб код был легче - предпочтительнее использовать блочную верстку, но это целое искусство. В качестве примера - посмотрите http://www.csszengarden.com/ - к одному и тому же ХТМЛ прикручены разные CSS-файлы и показано, чего можно добиться используя чисто CSS1.
Соответственно, выносим все позиционирования и пр. в отдельный .css, скрипты - .js, и уже лучше. Тщательно анализируем каждый тег на предмет нужности. Стараемся использовать дивы, поскольку и код легче (чтоб обозначить блок - один тег вместо трех <table><tr><td>), и по логике вернее (вообще, таблички разрабатывались именно для того, чтоб делать таблички - календарики, прайсики и т.д., а не для верстки). Еще полезно раза 3 с интервалом в неделю переверстывать все целиком (если конечно есть возможность через 1 шаблон работать со всем сайтом и позволяет время).
Но я в очередной раз повторяю, что перестал почти верить в силу внутренних факторов. Можно месяц просидеть над кодом, высчитывая всякие density и куда-бы еще h1 втиснуть, а тебя обойдет сайт на флеше, у которого ключевики только в титле, зато ссылок вагон и маленькая тележка.
На счет валидности - я тут когда-то спрашивал, сказали, что толку от нее никакого. Не так давно пришлось писать функции разбора чужих документов, и тут-то я почуствовал, насколько трудно парсить документы с ошибками. Быстрее всего обрабатывается валидный XHTML, с просто HTML проблем уже больше, но реализуемо, а вот реализовать 100% адекватный разбор HTML с ошибками (в рамках того бюджета и ресурсов сервера) у меня однозначно не получилось. Просто не представляется возможным учесть все ошибки. Для верстальщика незакрытый тег или там пересечение инлайнового и блочного элементов - фигня, ничего страшного. Правильно, когда документ разбирается на клиенте - не так уж и страшно, но на самом деле - необходимость на каждом последующем шаге разбора проверять возможность неявного закрытия, плюс еще помнить, что тег может быть закрыт явно, но потом, и еще куча проблем, а в конечном итоге - строить предположения, что же хотел сказать верстальщик. И не забываем, что робот яндекса работает на сервере, ему такие проблемы не очень-то улыбаются, и наверно проще принять первое предположение за правду, нежели возиться с кривыми тегами. Таким образом, в кеше может оказаться совсем не то, что предполагалось.
А вообще, красивый легкий код - это по дефолтам хорошо, чего я тут стараюсь-то :)
