С введением в строй гугловского sitemap вопрос хинтов для поисковых систем все равно остается актуальным.

Понятно, что контент обновляемого сайта можно поделить на две категории:
а) Динамическая. Это новые и часто обновляемые страницы. Необходимость быстрой индексации: высокая
б) Статическая. Фактически — это архив сайта. Изменяется редко, за исключением индексов. Необходимость быстрой индексации: низкая.
Третью категорию («левый контент»), формально не входящую в стостав сайта, рассматривать не будем.

Что предлгает Гугль? Он предлагает выложить список всех страниц сайта с указанием last modified и частоты изменения (для каждого url). Что с этим списком собирается делать Гугль — не совсем понятно (в документации это не описано).
Предположительно, Гугль начнет сверять sitemap со своим списком страниц. «Новые» страницы, отсутствующие в гугловском списке, пойдут в очередь на индексацию. «Старые» страницы сравниваются по last modified и, при необходимости, пойдут на реиндексацию.

Все это, конечно, хорошо… но! Что-то меня не радует необходимость перестраивать sitemap после каждого обновления на сайте/блоге. А это, между прочим, не одна тысяча url.
Поэтому, на мой взгляд, было бы логичней не смешивать все в один котелок, а отделить мух от котлет и учитывать каждую категорию отдельно. Динамическую часть получать из «облегченного» rss, а статическую — из списка разделов (тот же sitemap, но не по отдельным url, а по разделам). А для каждого раздела еще можно указать, какие страницы индексировать в первую очередь, а какие — вообще нежелательно (например, «версия для печати»). Где-то так…

Если я присутствую на нескольких сервисах, и каждый из них предоставляет openid.server — кому оказать предпочтение?

Никому, случайно, сабж не нужен? А то можно взять.

Ссылки на написанное so last-century! Давай ссылки в будущее уже! [ >>> ]

¹ — в LJ id будущего поста не угадать, а многие блоговские движки в линках собержат дату публикации
² — wiki позволяет ставить линки «на будущее», хотя и не выделяет это особо

Многие, наверное, удивятся, когда узнают, что Гугль не использует sitemap для индексирования сайта и, что интересно, загружает sitemap не тогда, когда он изменился — а тогда, когда Гугль сочтет нужным загрузить sitemap. Понятно, что глупо надеяться на то, что получив сигнал об изменении sitemap, Гугль ринется индексировать новые страницы.
Дальше возникает вопрос «кто виноват и что делать». В формулировке «зачем тогда нужен этот sitemap и какой с него толк».
Так вот, Гугль загружает и использует sitemap не для индексирования сайта, а для того, чтобы оптимизировать работу паука при индексировании этого сайта. Анализируя sitemap, Гугль узнает структуру сайта (со стороны своей, гугловской, колокольни), а делая diff двух sitemap — что и как часто изменяется. В-третьих, анализируя частоту изменений sitemap, можно прогнозировать динамику пополнения сайта и долю новых страниц. Это дает ему возможность заранее распланировать очередной визит своего паука.
Понятно, что при такой стратегии вы не можете повлиять на индексирование (только косвенно), зато облегчите работу гугловскому пауку.

Можно заметить, что при таком раскладе sitemap хорош для «статических» сайтов, отдающих объемную (по размеру) страницу с небольшим числом навигационных линков. И не имеет особого смысла для интенсивно-динамичных сайтов и блогов — новые записи лучше индексировать начиная с blog root, а не путем выковыривания их из sitemap (почему именно так, напишу позже).
А для форумов он вообще бесполезен.

Почему же использование sitemap для блогов неэффективно? Попробуем взглянуть на индексирование блога со стороны паука поисковой системы.

Метод номер 1. Паук заходит на blog root и начинает обход по тем линкам, которые там упомянуты. Несложно догадаться, что упомянуты там линки на самые последние записи.

Лирическое отступление. Добавление одной новой записи в блог приводит не только к созданию новой страницы, но и к изменению 5–10 связанных с ней страниц (раскладка по ключевым словам/категориям, архивы года/месяца/дня и т.д.). Исходя из этого факта несложно прикинуть количество страниц в блоге с 1000 записями (небольшой блог).

Теперь переходим к методу номер 2. Робот загружает sitemap. Так как число действующих страниц в 2–4 раза превышает количество записей, то sitemap из-за довольно большого объема загружается раз в 48 часов. Допустим, что за это время вы добавили 5–10 новых записей. Поэтому анализ sitemap выявляет 50 новых и изменившихся страниц.
Вопрос на засыпку: в каком порядке паук начнет их индексировать?
А поскольку паук индексироует не сплошным методом («ковровое индексирование» может завалить сервер), а «порциями», пытаясь достичь равномерного покрытия, то вопрос становится еще более интересным.
И это — не считая «убитых» на генерацию sitemap ресурсов сервера.

Какой из двух методов для вас более привлекателен?

Раньше были web-обзоры, теперь вот появились блог-обзоры… все возвращается на круги своя.

зы. Я просто констатирую факт.

Bonus track: Кошмарные домашние блоги

Интересно, а какие почтовые клиенты поддерживают xml так же хорошо, как и html?

У них есть деньги — они думают, что у них есть власть, у них есть секс — они думают, что у них есть любовь, у них есть движок — они думают, что они блоггеры…

Для внимательного фтыкания: «Скучаю по старым блоггерским временам» или «Как начинались блоги в России»

ps. (философски) Хороший блоггер — мертвый блоггер

Кстати, а никто не хочет написать «движок» для GTD? Для работы под web-сервером. Сама по себе техника GTD несложная (image,140K app.) , но за счет нюансов задача обещает быть интересной и нетривиальной.
Движок возможен в двух вариантах — personal и groupware (возможность групповой работы как раз очень интересна, особенно для небольшого коллектива). А на клиентской стороне мирно фурычит ajax…

ps. По прикидкам, такая штука будет круче «обычного» органайзера.