Но пользователи Битрикс сталкивались постоянно с неудобством, что это надо заходить куда-то, что-то жать, ждать ждать. Бяка. Да еще и постоянно вылетало из головы. В итоге, как правило, ни один сайт на Битрикс не имеет актуальной карты сайта. Но теперь это позади. [spoiler] Для тех кто вдруг не в курсе, что это за такая карта и в чем ее польза, рекомендую почитать об этом на Гугле и Яндексе. Если кратко, то плюс следующие:
Уменьшение нагрузки на сайт за счет более быстрого нахождения и добавления страниц сайта в индекс поисковиков и более быстрого нахождения поисковиком изменившихся страниц.
Более быстрое попадание сайта в результаты поисковой выдачи поисковика.
Более полное индексирование сайта поисковой системой. Часто определенное количество страниц сайта не индексируется, хотя ссылки, ведущие на них, корректно распознаются поисковыми роботами. Причина – расположение ссылок на эти страницы в глубине сайта, т.е. поисковый робот просто не доходит до них и, соответственно, не находит эти страницы.
Раньше все эти плюсы инструмента перечеркивались, так как никто вовремя не актуализировал карты. Сейчас проблема решена.
А решил я проблему выпуском модуля Актуальная карта сайта. Модуль делает следующие вещи:
После сохранения элементов инфоблока, если они есть в индексе, добавляет их в карту сайта.
Или изменяет информацию об оном, если ссылка уже есть в файле (меняет дату модификации).
При переполнении одного файла, автоматически создает новый, начинает наполнять его.
Конечно же поддерживается многосайтовость.
Чтобы карта сайта у вас постоянно актуализировалась, требуется:
Купить и установить модуль (900 руб. с партнерскими скидками). Есть демо-режим на 10 дней.
Выполнить (по желанию) переиндексацию модуля поиска.
Обращу внимание, что я пока не сделал поддержку форумов, блогов и статических страниц, ибо пока не требовалось, но после первых покупок и заявок, обязательно сие сделаю.
Резюмирую пост и комментарии поста:
1. Карта (сама по себе) хороша настолько насколько заявляют об этом поисковики (выкладки и ссылки я давал в посте). 2. В моем случае карта послужила лишь катализатором, при котором поисковик ЕЩЕ быстрее проиндексировал сайт и (к сожалению) заключил его в фильтры. Кстати, сайт уже выпустили. Но это лишь подтверждает, что карта (сама по себе) по-прежнему отлично работает. 3. Сам по себе модуль никак не вредит карте сайте, он лишь поддерживает ее актуальность. Вы можете и вручную поддерживать ее актуальность, заходя несколько раз в день на форму переиндексирования карты и запуская механизм. Но кому-то это надоедает, кто-то забывает, поэтому и родился данный модуль.
А еще есть такой момент: 1. существует страница со списком новостей например /news/ 2. добавляется новая новость
Содержимое указанной страницы по факту изменилось и нужно меня ее дату модификации в XML, но дефолтная карта битрикса этого не знает.. а у тебя эта ситуация обрабатывается?
Ром, как ты сам понимаешь, технически много нюансов (компонент новостей может быть в куче мест). Но я могу дергать урл списка новостей из настроек инфоблока и очищать его дату: http://my.jetscreenshot.com/18603/201...8-r5mg-7kb
Устроит? Можно пойти еще серьезнее и менять атомы карты для каждой из секций, к которым принадлежит элемент (/news/section/1/, /news/section/2/ и так далее). Ну а страница элемента обновляется и так уже.
Ну, наверное стоит так серьезно заморочиться только спецом для какого-то серьезного проекта, которому нужна карта сайта действительно актуальная на 99% Для большинства это не нужно
Антон, я только сейчас поняла, что мы с вами одновременно практически занялись проработкой одной и той же темы, но я не читала этот ваш пост, когда занялась своей sitemap. Представляю, как все выглядело со стороны.
Антон, это точно. Только я бы не стала париться над созданием 2й версии своей sitemap, если бы знала, что можно вместо этого купить вашу - мне срочно нужна была для клиента, и я все свое воскресение убила . Кстати, маркетплейс не показывал ваше решение в поиске по слову sitemap на тот момент.
Тоже не со зла, а только лишь в качестве констатации факта хочу отметить, что ваше решение не подходит для использования в крупных интернет-магазинах, интегрированных с 1С.
В ходе импорта во время вставки или обновления элемента каталога на сайте, где установлено ваше решение, будет происходить дополнительный инсерт в базу - вы повесили добавление агента на события OnAfterIBlockElementAdd и OnAfterIBlockElementUpdate.
Эти агенты отрабатывают на клике пользователя, и даже тот факт, что вы бьете файл sitemap на части - не спасет в данной ситуации. Агенты ваши будут запускаться раз в секунду, и начнут исполнятся еще до того, как закончится импорт, увеличивая нагрузку на и без того загруженный импортом сервер в разы, не говоря уже о том, что мне жаль пользователя, на чьем клике начнет в этой ситуации отрабатывать ваш агент. Думаю, в качестве покупателя он будет потерян.
ИМХО, на средненьком хостинге - виртуальной площадке мастерхоста за 1100р в месяц, который я считаю эталонным при отладке интеграции, импорт каталога из 6000 товаров + ваше решение - и сервер сдохнет.
С другой стороны, даже если вы отделите события обновления/добавления элемента, происходящие при импорте от тех, что происходят после добавления/редактирования элемента из админки, и не станете обновлять карту при импорте каталога, тогда у вашего решения появится другой недостаток - после импорта каталога карта будет неактуальна.
Юлия, да, о таком поведении я уже думал и будет выпущено иное решение. После импорта будет фактически один агент запускаться, который и обновит всю базу. Отделять ничего не надо, на все будет одна схема.
А агенты я всегда и настоятельно рекомендую переводить на крон. Всячески ратую за то, чтобы это ввести в обязательные чеклисты монитора.
Да, агенты на кроне - это здорово, но ведь большинство людей, к-е будут устанавливать ваше решение не знают, что их нужно на крон переводить. Или вы будете каждому из них объяснять? Кроме этого, мне в вашем решении не понравилось, то, что ваши обработчики OnAfterIBlockElementAdd и OnAfterIBlockElementUpdate спрятаны в вашем классе. Придет потом человек интегрировать сайт с 1С, и ему не придет в голову искать их там у вас в решении, формирующем sitemap. А ведь нам каждая милисекунда при импорте элемента инфоблока важна - из них часы складываются. Если бы мне пришлось оптимизировать импорт на сайте, где установлено ваше текущее решение, я бы однозначно отказалась от использования обработчиков OnAfterIBlockElementAdd и OnAfterIBlockElementUpdate для создания агентов (ведь функция AddAgent делает запрос к БД, а когда их там будет несколько тысяч - этот запрос будет выполняться не быстро. Подозреваю, что таблицы, хранящие агентов, вообще не рассчитаны на хранения такого количества агентов). Нет, однозначно нет. Даже если эти агенты будут отрабатывать потом по крону.
Если вы хотите, чтобы карта перестраивалась после сохранения/изменения элемента - мне кажется, лучше повесить вызов вашей функции непосредственно на форму редактирования элемента в админке (хотя я не представляю, как сделать такое решение коробочным, но, возможно, вы знаете) - можно повесить событие на кнопку сохранения элемента в админке и по ее нажатию посылать аякс запрос скрипту, обновляющему карту сайта - админу в это время показывать прелоадер, а после отработки скрипта уже непосредственно сабмитить форму. Тогда после редактирования в админке карта будет обновляться, а в процессе импорта - нет. После импорта по-любому понадобится решение, работающее по крону.
И все вышесказанное опять же не отменяет того, что и вы, и я - забыли про пагинацию - вспомнила о ней, когда прочитала чей-то злобный комментарий к вашему решению. А это, действительно, важно. Поэтому мой "дубль 2" - идет в утиль, я готовлю "дубль 3", не обладающий ни одним из указанных недостатков.
1. Агент будет один. Совершенно согласен, тысячи агентов никуда не годятся. 2. Инсерты в БД самый мелкозатратный ресурс.. Тысячи инсертов в минуту - пустяки. (и это не про таблицу агентов) 3. Пихать пагинацию в карту - бред. Ни одному поискоивку не нужны списки списков ваших элементов. Ему нужны конечные элементы. Более того, пагинация является мусором для поисковика. 4. Переводить на крон - надо, подсказывать это в самом решении - надо стараться (в особо сложных случаях я это и делаю). 5. Вешать что-либо на реакцию к форме в админке - костыль жуткий. 6. Ну и самое главное - решайте проблемы по мере их поступления. Всегда будут те 5%, которые вернутся и назовут мудаком. На то они эти 5% и нужны. Остальные 95 останутся довольны. И то, запросы 5% будут проанализированы, вынесена температура проблемы и проблема будет решена. В самом крайнем случае, я верну деньги.
не понравилось, то, что ваши обработчики OnAfterIBlockElementAdd и OnAfterIBlockElementUpdate спрятаны в вашем классе
эмм... надо было переписывать init.php?
Чего еще хотел сказать. В защиту _запрета_ индексации постранички. Никогда не было у вас ситуации, что вы что-то ищите, поисковик находит, кидает вас на страницу списка статей, и... там нет своей статьи уже? Потому что она ушла куда-то по постраничке. И ладно мы, прожженные веб-мастера, открываем копию поисковика и там находим заветную ссылку, а обычный народ? В общем, мое мнение: - пихать страницы в карту нельзя, хотя бы для того, чтобы понизить внимание поисковика к этим страницам - если и пихать, то обратную навигацию, что является ноу-хау Битрикса (?) и решает описанную проблему, тем, что постраничка идет с конца и новый элемент всегда остается на этой странице (мое личное мнение - ужасно неудобно и как-то не сложилось исторически, применяют единицы) - если и пихать, то постраничку того, у чего нет детального, но даже в этом случае я бы рекомендовал сделать детальные страницы хотя бы для поисковика
Это более развернутый ответ на тот злобный комментарий про постраничку.
Так что, не надо мусорить Рунет, не надо пихать постранички в карту
Спасибо за аргументированный и развернутый ответ. Надеюсь только, что вы не слукавили перед самим собой. Мой кумир, чьи выступления в записи я готова смотреть снова и снова, - не станет отрицать фактов ради победы в маленьком споре. Хочу процитировать его: "Я радею за исключительное качество каждого компонента."
Антон, так и не понял, есть ли возможность обрабатывать редиректы, чтобы в sitemap попадала не статическая страница /about.php, а её редирект /about/ ? Ведь если мы делаем все ссылки, даже для отдельных страниц, без .php и .html а /название_страницы/ и убираем маску включения "*.php", то эти страницы проиндексированы не будут и в sitemap не попадут.
Евгений, а зачем убирать маску включения php? Это ключевой момент при определении движком (а не модулем) попадает ли страница в индекс (а из этого следует и попадание в карту).
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».