Ну и уж точно кэш RealURL не содержит даты последнего изменения содержания страницы, которая также важна для sitemap. Там кажется есть только дата генерации URL, а это не то же самое.

Ну нет конечно. однако я думаю скрипт получится не такой сложный, если брать таблицы cashe_pages, pages, tx_realurl_urldecodecache, tx_realurl_patchcache - то объединяя эти данные вполне можно построить sitemap.xml - тут естественно в sitemap попадут только страницы, которые хоть раз просматривались...

Вот как раз с pages нет никаких проблем построить sitemap. Речь изначально шла о том, что на одной странице (из pages) может стоять плагин как USER_INT - значит caсhe_** не помогут. Это может быть тот же tt_news, который выводит 10 000 новостей - фактически "виртуальных" страниц о которых ни ядро, ни кэши ничего не знают (или еще не знают). Ведь что бы получить URL страницы конкретной записи нужно знать конфигурацию плагина (из TS), то как он формируется ссылки на "подробнее" (PHP код плагина) и добавить к этому конфигурацию RealURL.

Например, я хочу что бы добавленная на сайт новость сначала появилась в sitemap, и только потом с некоторой задержкой стала доступна в списке новостей в FE. Зачем думаю понятно - что бы контент не успели своровать раньше, чем поисковики проиндексируют новую страницу.

PS: В общем задача в таком виде и обсуждалась сначала ветки.

Я о том тоже и говорю, что построить sitemap возможно лишь когда страница была открыта и посещена. Кстати, второй вариант - программка-обходчик страниц сайта по внутренним ссылкам на них с построением карты.
А вопрос авторства сейчас неплохо решается соответствующими сервисами в том же Яндекс.Вебмастере. На гугле такое по моему то же есть.

Из реальной жизни - изменения, добавления делаются порядка в 2000 записей сайта ежедневно (разных, не только новостей). Всего сайт содержит порядка 40-50 тыс. страниц. Так что этот вариант отпадает - проблематично даже раз в сутки просканить сайт, а хочется иметь карту "в реальном времени" или хотя бы с обновлением в 5-15 минут.

На Яндексе можно подтвердить уникальность текста от 2000 знаков в ручном режиме. А мы, например, оперируем базой объявлений недвижимости и компаний.
Ручной режим не подходит. Вид информации не подходит под требования Яндекса об уникальности и его нельзя подтвердить. Информацию по объявлениям очень многие тырят. Поисковиков много и у каждого свой способ подтвердить уникальность, или вообще нет такого способа.
Sitemap же универсален, его все понимают.

Да-да-да. Всё упирается в объемы. Теперь вижу по количеству страниц и обновлений.
Тогда надо просекать логику работы используемых экстов, прописанные в конкретном данном случае правила формирования адресов realurl. Скорее всего какого-то общего, подходящего для всех решения (куда бы ни установил - работает) - не получится. Всегда надо будет допиливать под конкретные условия.

Да, для небольшого редко обновляемого сайта проблем с картой сайта нет.
В таком случае можно организовать все данные в удобном виде для генерации sitemap и обойтись одним TS конфигом, который приведен в этой ветке выше уважаемым -=UncleByte=-.

Да уж, одного, универсального решения тут быть не может. Ведь создатели расширений - кто в лес, кто по дрова, как хотя, так и пишут. Знали бы вы, что твориться в мультишоп, я вот до сих пор логику работы до конца не понял...
Кроме того, сайтмап - это уже поисковая оптимизация, за работу над которой нужно брать отдельную плату... Конечно хотелось бы без проблем и все в одном флаконе, да вот нет.

Вот сейчас тоже копал, накопал экст Дмитрия Дулепова dd_googlesitemap http://typo3.org/extensions/reposito..._googlesitemap корректно работающий с tt_news. Буду пробовать. Может быть в вашем случае пригодится его логика?

Вернулись к исходному посту темы, который как раз начался с dd_googlesitemap :)