16-в-1 SEO-мастер: модуль SEO умного фильтра, авто SEO, ЧПУ-пагинация, canonical, редиректы, и др

Если Вы установили демо-версию модуля и демонстрационный режим истек, но Вы не успели попробовать модуль в работе, сообщите об этом нам, мы можем повторно включить демо-режим. В общем случае, для сброса демо-режима нужно выполнить следующие указания:

1. создать рез. копию сайта, хотя бы базы данных,

2. деинсталлировать модуль (все данные будут удалены!),

3. стереть данный модуль с сайта (соотв. опция доступна в списке модулей),

4. выполнить SQL-запрос (в админке на соотв. странице в разделе "Инструменты": Административный раздел - Настройки - Инструменты - SQL-запрос):
   

   DELETE FROM `b_option` WHERE `MODULE_ID`='webdebug.seo';
   

5. сбросить весь кеш на сайте,

6. сообщить нам адрес сайта и владельца лицензии для проверки и сброса срока демо-версии на Вашем сайте,

7. после нашего ответа повторно установить модуль из Маркетплейс .

Ни один из наших модулей не имеет никаких ограничений или изменения условий работы в демо-режиме (за исключением механизма сохранения профилей в Антирутине).

Другими словами, никакие проблемы не могут быть связаны с демо-режимом.

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

При этом даже если на сайт впервые установить данный модуль в демо-режиме, и сразу удалить - то повторная установка будет невозможной.

В таком случае выполните все шаги, описанные в пункте «Как продлить DEMO» (если модуля на сайте нет, пункты 2 и 3 пропустить), либо напишите нам, мы поможем установить.

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

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

Поэтому, на каждом сайте в рамках одной системы можно настроить совершенно разную работу модуля.

Основная задача, которую решает модуль «SEO-мастер» - задача уникальных тегов для разных страниц умного фильтра. Это - самый простой и доступный способ значительно увеличить число страниц с качественными SEO-данными для продвижения.

Например, Вы можете сгенерировать для продвижения страницы «Велосипеды горные» и «Велосипеды дорожные» - и так для любых свойств и значений фильтра. Более сложный пример страниц, которые может сгенерировать модуль: «Ноутбуки диагональ 15.6 с подсветкой клавиатуры» - здесь представлена комбинация двух параметров - диагональ и наличие подсветки клавиатуры.

Для генерации ссылок Вы можете использовать фильтр по цене, и для товаров с ценой, например, менее 1000 рублей дополнять тексты фразой «недорогие».

Кроме SEO для фильтра, модуль позволяет легко управлять редиректами по https (редирект на https://) и www (убрать или добавить www из домена). Кроме того, он может убирать index.php из адреса, добавлять слеш в конце адреса.

Также, модуль добавляет такие уникальные функции как избавление от некрасивых адресов постраничной навигации вида ?PAGEN_1=2 (с заменой на более красивые варианты, например: /page-2/ или ?page=2) и закрытием внешних ссылок от индексации (возможен, например, вариант с предупреждением: "Вы уверены, что хотите перейти по внешней ссылке?").

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

Да, модуль корректно работает на версиях PHP 8.0 и 8.1.

Установка модуля «SEO-мастер» не активирует функционал модуля, все функции требуют индивидуальной настройки. Важно учесть, что все функции включаются только при необходимости: ни одна из функций не является обязательной (за исключением настройки https - это необходимо для того, чтобы получаемые ссылки были с https вместо http).

Опишем общий алгоритм настройки модуля после установки.

1. Настройка https. Если Ваш сайт работает по протоколу https, модуль должен понимать, что ссылки необходимо использовать не с http, а с https. Для этого перейдите в раздел модуля «Сайты», и для нужного сайта установите режим «HTTPS: да». Это приведёт к тому, что при открытии сайта через http:// модуль будет выполнять редирект на https://. Также это включает режим генерации всех ссылок через https://.
2. Настройка SEO для умного фильтра.
1. Создание профиля. В профиле указываются параметры, критически важные для корректной генерации адресов - выберите привязку к сайту, укажите инфоблок с товарами, выберите используемый на сайте тип фильтра, и укажите шаблон используемых на сайте реальных адресов инфоблока (посмотреть параметры можно, например, в параметрах компонента «Каталог»). Также, здесь можно указать дефолтный шаблон генерации «красивых» адресов в правилах генерации, создаваемых по данному профилю.
2. Создание первого правила генерации. В связи с особенностями архитектуры системы 1С-Битрикс и архитектуры нашего модуля, правил будет создано много, возможно даже - очень много. Каждое правило подразумевает генерацию набора ссылок для одного раздела по одному набору ссылок. Например, приведём примеры правил для одного раздела футболок: "футболки по цвету", "футболки по полу", "футболки по полу и цвету", "футболки по материалу", и т.д. В каждом правиле будут сгенерированы свои ссылки, содержащие все комбинации выбранных параметров для каждого раздела. Самое первое правило - самое ответственное, Вам необходимо понять, как работает модуль, и в дальнейшем Вы будете создавать новые правило быстро и легко.
3. Разбивка правил на группы. Учитывая, что правил будет много, советуем сразу разбивать правила по группам. Например, создать в корне группу «Одежда», в ней подраздел «Футболки», и в нём уже все правила, относящиеся к данному разделу.
4. Создание остальных правил. После настройки и проверки первого правила, предстоит создавать новые правила - по подобию первого.
3. Вывод дополнительных описаний на сайте. Для каждой ссылки (в каждом правиле) модуль генерирует (если Вы задали) собственные дополнительные описания (те, которые задаются в HTML-редакторах). Сами по себе они, конечно же, не выводятся. Поэтому необходимо их выводить вручную. При этом готовую инструкцию для каждого сайта мы вывести не имеем возможности, поскольку на каждом сайте это делается по-своему. Общая информация по выводу данных из ссылок приведена здесь.
4. Настройка АвтоSEO. Данный механизм предусматривает добавление на страницу мета-тегов в зависимости от раздела и выбраных параметров фильтра. Работает только для стандартного компонента bitrix:catalog.smartfilter. Функционал включается в настройках модуля для каждого сайта в отдельности. При этом в код компонента требуется добавить код, который будет сообщать модулю о заданных в фильтре параметрах.
5. Вывод кнопок перелинковки. Перелинковка - это вывод ссылок (показываются как кнопки) модуля. Самое важное и сложное на данном этапе - правильно выбрать режим. Для вывода кнопок используется компонент webdebug:seo.links.
6. Настройка канонических адресов. Включается в настройках модуля отдельно для каждого сайта, имеются разные режимы (авто, php, и произвольные). В общем случае, модуль генерирует канонические адреса автоматически, но в некоторых случаях этого функционала не хватает, и требуется либо добавить функционал установки канонических адресов для разделов и товаров (через php-код), либо задать какие-то произвольные правила (для особых случаев).
7. Настройка постраничной навигации. В настройках модуля можно включить режим «красивых» адресов постраничной навигации, избавившись от страшных параметров ?PAGEN_1=2. При этом может потребоваться дополнительная настройка для компонента bitrix:catalog.section.
8. Ограничения для внешних ссылок. Если Вы хотите взять под контроль внешние ссылки, в настройках модуля (для каждого сайта отдельно) укажите соответствующие параметры - распространённым случаем можно считать простое добавление noindex и nofollow, однако можно сделать и более продвинутый вариант - предупреждение при открытии ссылок. Также, для некоторых доменов можно отменить такие правила.

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

Приведём пример вывода данных для заголовка H1 четырьмя способами:

1. global $wdSeoUrlData; print $wdSeoUrlData['SEO_PAGE_TITLE'];

2. print $GLOBALS['WD_SEO_URL_DATA']['SEO_PAGE_TITLE'];

3. print \WD\Seo\Page::getCurrentUrlData()['SEO_PAGE_TITLE'];
   

4. print $APPLICATION->wdSeoUrlData['SEO_PAGE_TITLE']; # Этот способ уже не рекомендуется, т.к. DEPRECATED

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

• ID - числовой идентификатор ссылки,
• SEO_TITLE - Заголовок окна браузера
  
• SEO_DESCRIPTION - SEO описание страницы
  
• SEO_KEYWORDS - SEO ключевые слова
  
• SEO_PAGE_TITLE - H1-заголовок
  
• SEO_BREADCRUMB_ITEM_NAME - Название для цепочки навигации
  
• CANONICAL_URL - канонический URL,
  
• SEO_TEXT_1 - дополнительное описание №1
  
• SEO_TEXT_1_TYPE - тип дополнительного описания №1
  

При этом, если в настройках модуля заданы собственные коды для свойств, то вместо SEO_TEXT_1 и  SEO_TEXT_1_TYPE будут другие коды. Например, если задать для первого описания код DESCRIPTION_MAIN, то данные для него будут поступать как DESCRIPTION_MAIN и DESCRIPTION_MAIN.

Проверить, какие данные из ссылки доступны на странице, можно распечатав весь массив в соответствии с вышеуказанными способами, например:

print '<pre>';
print_r($APPLICATION->wdSeoUrlData);
print '</pre>';

Пример вывода на сайте:

if(mb_strlen($APPLICATION->wdSeoUrlData['DESCRIPTION_BOTTOM'])){
  ?>
    <div class="wd_seo_description_bottom">
      <?=$APPLICATION->wdSeoUrlData['DESCRIPTION_BOTTOM'];?>
    </div>
  <?
} 

Кроме того, дополнительные описания можно вывести на сайте с помощью HTML-комментариев (проверьте, что галочка для использования этого функционала включена в настройках модуля), например:

<!--DESCRIPTION_BOTTOM-->

В модуле реализован механизм управления ссылками, при котором для каждой ссылки задаётся два адреса - реальный («старый», «некрасивый») и желаемый («новый», «красивый»). Желаемый адрес часто называют ЧПУ («человеко-понятным урлом»).

При открытии публичной части сайта модуль берёт текущий адрес, по нему ищет соответствие (одновременно по реальному и желаемому адресам) - и если есть соответствие, то выполняет необходимые действия:

• если текущий адрес является реальным для одной из ссылок, модуль выполняет редирект (код 301) на желаемый адрес,

• если же текущий адрес является желаемым, то модуль подставляет из ссылки необходимые SEO-данные и показывает страницу, указанную в реальном адресе (для этого используются правила обработки адресов Битрикс - т.е. модуль определяет целевую страницу, для неё определяет необходимое правило обработки и, если оно найдено, подключает скрипт из этого правила).

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

Настройка состоит из нескольких этапов.

Прежде всего необходимо создать профиль настроек.

Профиль - это набор настроек, которые в дальнейшем используются при генерации ссылок. Такая система профилей создана для того, чтобы при дальнейшей настройке не приходилось каждый раз указывать какие-либо дополнительные настройки - всё указывается в одном месте и один раз. Это значительно упрощает настройку и снижает вероятность проблем, связанных с указанием некорректных параметров.

При настройке профиля указываются такие параметры как: активность (влияет на активность ссылок, относящихся к профилю), привязка к сайту, инфоблок, тип умного фильтра, шаблон реальных ссылок (модуль будет считать их реальными адресами), валюта (используется при фильтрации по цене).

Также, профиль может предлагать дополнительные настройки в зависимости от выбранного типа фильтра - например, для умного фильтра без ЧПУ предлагается к настройке имя фильтра (по умолчанию - arrFilter) и имя GET-параметра для указания раздела (по умолчанию - SECTION_ID).

Далее необходимо создать правило генерации ссылок.

Правило описывает один логический набор ссылок. Например, ссылки заданного типа для какого-либо раздела. Генерация ссылок будет доступна после настройки параметров правила.

Настройка правила предлагает указание таких параметров как: активность (как и активность в профиле, влияет на активность ссылок, относящихся к данному правилу), профиль (настройки будут браться из этого профиля), раздел инфоблока (это влияет на список доступных свойств).

После настройки базовых параметров необходимо настроить условия фильтра, заполнить шаблоны SEO-данных, сохранить. После этого доступна генерация ссылок, которая выполняется нажатие кнопки «Сгенерировать».

Кстати, при настройке фильтров учитывайте, что значения показываются только используемые. Другими словами, неиспользуемые в данном разделе значения данного свойства не показываются.

Наконец, необходимо проверить созданные ссылки.

В большинстве случаев достаточно проверить несколько ссылок. Ссылки, относящиеся к правилу, показаны на странице этого правила (вкладка «Страницы»). Открыть конкретную ссылку можно по двойному клику на ней (клик на адрес ссылки открывает данный адрес).Необходимо проверить корректность заполнения SEO-полей по шаблонам, и корректность генерации адресов - реального и желаемого.

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

При создании (изменении) ссылки модуль автоматически добавляет (изменяет) информацию в поиске, если у ссылки не отмечена галочка «Запретить добавление в поиск».

Добавление в поиск подразумевает добавление информации о ссылке в индекс модуля «Поиск». В индекс добавляются только значения SEO-полей. Служебное название и описание ссылки в индекс не добавляются.

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

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

Активность ссылки для SEO умного фильтра определяется активностью как самой ссылки, так и родительского правила генерации, так и профилем: ссылка считается активной, если активность указана как для ссылки, так и для правила, так и для профиля одновременно. В противном случае ссылка считается неактивной.

Активность ссылки, не относящейся к SEO умного фильтра определяется только активностью самой ссылки.

Принцип работы SEO умного фильтра в нашем модуле основан на сопоставлении реального и желаемого адресов. Соответственно, для корректной работы модуля необходима корректная генерация реальных адресов умного фильтра. Это выполняется отдельным механизмом модуля по работе с разными типами умного фильтра. Данный механизм основан на системе плагинов, что позволяет добавить в модуль поддержку любого умного фильтра. Штатно модуль поддерживает только стандартный умный фильтр Битрикса в двух вариантах: с ЧПУ и без ЧПУ - тип фильтра выбирается в настройках профиля.

В момент генерации ссылок (в правиле генерации) модуль знает тип фильтра (указан в настройках профиля) и, имея список полей фильтра (указаны в правиле генерации), генерирует для каждой комбинации значений фильтра свой адрес (URL) - этот адрес совпадает с адресом, который генерирует Битрикс при работе умного фильтра в публичной части.

При этом, в фильтре без ЧПУ порядок параметров не всегда соблюдается, соответственно адрес, генерируемый модулем и адрес, генерируемый Битрикс, в некоторых случаях могут немного различаться между собой порядком параметров.

При необходимости, в модуль можно добавить поддержку любого типа фильтра - для этого необходимо создать класс, расширяющий класс \WD\Seo\Filter (примеры - в папке /bitrix/modules/webdebug.seo/plugins/filter) и просто подключить его в событии OnFindPluginsFilterType.

Прежде всего, модуль по адресу текущей страницы определяет целевую ссылку модуля (это происходит на событии onProlog): если она найдена, модуль запоминает полный набор её данных, и в дальнейшем, в момент вызова события OnBeforeEndBufferContent, устанавливает SEO-данные из этой страницы.

В этот момент (событие ) модуль устанавливает:

• четыре основных SEO-параметра (title - заголовок окна браузера, description - описание страницы, keywords - ключевые слова, h1 - заголовок страницы),

• название страницы в цепочке навигации («хлебные крошки»),

• флаг включения или отключения индексации (мета-тег robots),

• канонический URL (который совпадает с желаемым адресом из ссылки).

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

Непосредственно перед установкой SEO-данных модуль вызывает событие OnSetPageMeta, которое можно использовать для модификации SEO-данных.

Значения дополнительных текстовых описаний никуда не устанавливаются, только сохраняются, чтобы Вы могли вывести их на сайте там, где это необходимо.

Несмотря на то, что SEO-данные страницы устанавливаются ближе к концу выполнения страницы (событие OnBeforeEndBufferContent близко к самому концу генерации страницы), на сайте также могут существовать обработчики, которые могут переопределять SEO-данные, установленные модулем, из-за чего будет создаваться впечатление что «модуль некорректно работает». В таком случае необходимо либо пересмотреть необходимость данных обработчиков, либо после их выполнения вызвать метод \WD\Seo\Page::setCurrentUrlMeta().

Авто SEO для фильтра это функционал автоматической генерации мета-тегов для страниц фильтра без настройки отдельных правил.

Другими словами, это возможность смены SEO-данные страницы при любом выборе в умном фильтре. Например, в разделе с футболками Вы выбрали для фильтра размер M и красный цвет. В заголовке страницы Вы увидите: «Футболки: размер M, цвет красный».

Шаблон настраивается, множественные значения учитываются, выбранные диапазоны цен и числовых свойств также учитываются. Таким образом, это лёгкий способ решить насущную проблему SEO для умного фильтра одним выстрелом - и всё это настраивается за на несколько минут.

При этом, прежний функционал SEO для умного фильтра не теряет актуальность. Он позволяет настроить более качественные SEO-данные для отдельных разделов или типов страниц: если для страницы сгенерированы собственные данные, авто SEO не действует.

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

Внимание! Требуется установка данного функционала в шаблон фильтра. Самый простой способ - напишите нам, мы оперативно поможем (понадобится доступ к сайту). Либо можете сделать это самостоятельно. Всё что требуется - разместить в шаблоне компонента умного фильтра (bitrix:catalog.smart.filter) следующий код (лучше это сделать в файле component_epilog.php шаблона фильтра):

if(\Bitrix\Main\Loader::includeModule('webdebug.seo')){
  \WD\Seo\SmartFilter\AutoSeo::set($arResult, $arParams);
}

После этого активируйте функционал в админке: Маркетинг - SEO-мастер - SEO для умного фильтра - Авто SEO для фильтра. И, если требуется, настройке собственные мета-теги.

Если у Вас в каталоге работает AJAX-фильтрация, в настройках главного модуля Вам пригодятся две опции:

• При ajax-фильтрации в умном фильтре подменять URL
• При ajax-фильтрации в умном фильтре подменять мета-данные

Нет, такой возможности нет.

Функционал «SEO для умного фильтра» подразумевает качественную настройку всех ссылок, а в столь массовом режиме высокого качества не добиться. Поэтому, одно правило можно настроить только для одного раздела и одного сочетания выбранных свойств.

Если Вы настроили правило для свойств, например, «Бренд», «Материал», «Тип», то это правило уже невозможно применить для двух свойств, т.к. в нём настроены SEO-тексты вида «товар бренда #PROPERTY_BRAND.VALUE# изготовлен из #PROPERTY_MATERIAL.VALUE# (#PROPERTY_TYPE.VALUE#)» - и при попытке использования этого правила только для свойств «Бренд» и «Тип» в текстах остаётся текс "изготовленные из #PROPERTY_MATERIAL.VALUE#" - соответственно, такой вариант в нашем модуле не возможен.

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

Если же Вам необходимо быстрое решение, используйте функционал «Авто SEO» - он позволяет минимальными усилиями (только установить небольшой код в шаблон фильтра и настроить один раз мета-данные) организовать автоматические SEO-данные на странице при переключении фильтра.

Такая возможность появилась в версии 22.8.0 модуля.

По умолчанию все коды свойств указываются как есть:

В таком случае мы получаем адреса вида /catalog/futbolki/cvet:krasnyi/

Чтобы добиться такой возможности, следует в начале кода свойства добавить символ @ чтобы получилось так:

После этого изменения мы получаем другие адреса: /catalog/futbolki/krasnyi-cvet/

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

Кроме цвета, это может быть полезно и для других свойств, например, свойство "Количество роз" (количество цветов в букете): удобнее использовать не "roz:7", а "7-roz", и т.д.

Также, имеется возможность отбросить название свойства, и оставить только значение, т.е. сделать не "roz:7" и не "7-roz", а просто "7": /catalog/rosy/7/ - для этого в поле «Код для ссылок» должен быть только символ решётки.

И третий вариант - собственный текст. Для этого значение должно начинаться с символа «!», например: "!krasnyi". Имейте ввиду, что это подходит только если в правиле генерируется одна ссылка, т.к. если их больше, то все ссылки будут иметь одинаковый адрес.

В модуле можно настроить фильтр не только по свойствам, но и по цене, хотя это используется редко.

Для SEO обычно не важно какая цена указана, поэтому сами числовые значения цен лучше не использовать. Но для некоторых категорий можно добавлять цену и устанавливать максимальное значение - напр., для категории "Футболки" можно установить максимальную цену 500 рублей. Т.е. на странице будут показаны товары ценой до 500 рублей. И в SEO-тексте в этом правиле можно дописывать "недорого", "выгодно", и т.п. Или наоборот - задать цену чтобы были отобраны только дорогие, и в SEO-текста дописывать "лучшие", "премиум", "дорогие" и т.п.

Именно так. Если в правиле генерации использовать свойства, не настроенные для фильтра - они сами по себе работать не будут. Т.к. модуль никак не влияет на работу фильтра. Модуль лишь узнаёт какие страницы генерирует фильтр и назначает им мета-данные.

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

Модуль имеет собственный механизм заполнения полей с макросами.

Прежде всего, доступны поля, заданные в фильтре - это могут быть цены и свойства товаров и предложений. Для цен доступны поля «От» и «До». Для свойств - простые значения. Это всё то, что заполняется из фильтра.

Например, мы создаём правило генерации по одному свойству - материалу. В заголовке указываем шаблон с макросом: «Сумки #PROPERTY_MATERIAL.VALUE#», после генерации получаем несколько ссылок, в которых подставленное значение соответствует выбору в фильтре для данной ссылки.

Учитывая, что ссылки относятся к разделам, правило генерации настраивается в контексте раздела, поэтому и при редактировании SEO-полей всё основано на текущем разделе. Т.е. все поля так или иначе привязаны к разделам, например «Поля раздела», «Свойства раздела», «SEO-поля раздела».

Также, нам всегда известен инфоблок, поэтому группы полей включают «Поля инфоблока».

Кроме этого, модуль добавляет некоторые дополнительные поля, например, минимальную и максимальную цену товаров в разделе по каждому из типов цен, а также число товаров в текущем разделе.

Использовать функции необязательно. Но они помогают «навести красоту».

Приведём только один пример. Допустим, у нас есть сайт доставки еды. Есть раздел "Пицца", и в нём настроен фильтр по ингредиентам.

Например, мы настроили правило для этих условий. Получили заголовок (в зависимости от настроек) вида "Пицца с Креветка". Такой вариант нам не очень нравится. Теперь займёмся наведением красоты.

Сначала свойство из состава приведём к нижнему регистру, для этого используем функцию модуля - toLower:

Пицца с ({=toLower(#PROPERTY_INGREDIENTS.VALUE#)}

Получаем "Пицца с креветка", всё равно плохо.

Теперь добавим обработку функцией склонения в творительный падеж (буква означает падеж) функцией morphyPhrase или morphyWord:

Пицца с {=morphyPhrase({=toLower(#PROPERTY_INGREDIENTS.VALUE#)}, "Т")}

Получаем "Пицца с креветкой" - это уже хорошо.

Можно пойти ещё дальше, если вместо "Пицца с креветкой" нужно "Пицца с креветками":

Пицца с {=morphyPhrase({=toLower(#PROPERTY_INGREDIENTS.VALUE#)}, "Т", true)}

И таким образом можно генерируемые SEO-тексты делать более качественными.

При этом, в модуле имеется достаточно много функций, но самое главное - можно использовать вообще любые PHP-функции, например:

{=php:my_function(12404324)}

или

{=php:\MyModule\MyClass::formatSize(12404324)}

При этом модуль позволяет автоматически подключать соответствующие классы, если необходимо.

При заполнении текстовые SEO-полей («Заголовок окна браузера», «Ключевые слова страницы», «Описание страницы» и др) справа от поля доступна кнопка с тремя точками, нажатие по которой открываем меню макросов. Обратите внимание на нижний пункт - «Примеры функций».

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

Все функции разделены на две группы: функции модуля (функции, реализованные в модуле) и PHP-функции (функции прямо из PHP и Битрикс, с префиксом «php:»). В качестве обучение разберём несколько примеров функций:

• {=first(#PROPERTY_1.VALUE#, #PROPERTY_2.VALUE#)} - этот код выберет из всех предложенных значений (их число не ограничено) первое заполненное. Особенно необходимо для случаев, когда одно и то же свойство для части товаров может быть заполнено в одном свойстве, для другой части - в другом. Полезный кейс - на конйе можно добавить константное значение, в кавычках - оно будет использовано, если другие значения окажутся пустыми.
  
• {=concat(", ", #PROPERTY_1.VALUE#, #PROPERTY_2.VALUE#)} - этот код склеит несколько текстовых строк с указанным разделителем.
  
• {=php:trim(#PROPERTY_1.VALUE#)} - этот код удалит лишние пробелы слева и справа в самом значении.
  
• {=php:str_replace("Холодный", "Горячий", #PROPERTY_1.VALUE#)} - этот код произведёт замены в указанном значении (в примере «Холодный» заменяется на «Горячий»).
  
• {=php:\WD\Seo\Helper::formatSize(12404324)} - это пример произвольный функции (Вы можете использовать любую доступную PHP- или Битрикс-функцию или метод).
  

Да, модуль допускает ручное добавление произвольной ссылки. В этом случае требуется указать только реальный и желаемые адреса, а также SEO-данные и настройки индексации, добавления в поиск и в карту сайта.

Это легко сделать так: зайдите на нужную страницу, нажмите кнопку «SEO-мастер» на панели кнопок, отредактируйте данные (также можете указать новый адрес для этой страницы), и сохраните. Дополнительных действий не требуется.

Блокировка ссылки это механизм защиты ссылки от дальнейших автоматических изменений генератором ссылок (вручную ссылки можно изменять всегда!). Для произвольных ссылок (созданных вручную) флаг блокировки также присутствует, но на данный момент не имеет никакого смысла, и никак не учитывается.

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

Приведём пример. Вы создали правило генерации, сгенерировали сотню ссылок. В дальнейшем, некоторые из них Вы редактировали, придавая SEO-данным более подходящий вид. Если оставить всё как есть, то следующее нажатие кнопки генерации ссылок приведёт к потере всех сделанных изменений. А если такую ссылку заблокировать, то она защищена от изменений.

Блокировка работает только для ссылок, создаваемых функционалом SEO умного фильтра. Поэтому для ссылок, добавленных вручную, блокировка не имеет смысла.

• Не блокировать изменения в ссылке - опция означает, что блокировка не используется, т.е. даже блокированные ссылки ведут себя как обычные незаблокированные, эту опцию можно применять, например, если у Вас много заблокированных ссылок и Вы решили временно или постоянно отказаться от блокировки.
• Блокировать только изменение адреса - опция запрещает генератору ссылок изменять «красивый» адрес: это даёт гарантию, что конечный адрес не изменится. При этом тексты и параметры ссылок будут каждый раз перезаписываться.
  
• Блокировать только изменение текстов - опция запрещает генератору ссылок изменять SEO-данные (заголовки и тексты). Это позволяет предотвратить случаи потери внесённых вручную изменений в SEO-текстах.
  
• Блокировать изменение адреса и текстов - опция совмещает в себе два предыдущих варианта, запрещая изменения адреса и всех SEO-данных. Генератор ссылок может только изменять параметры ссылки.
  
• Блокировать любые изменения в ссылке - опция запрещает генератору ссылок изменять данные в сгенерированных ранее ссылках. Это позволяет быть уверенным, что все сгенерированные данные не будут изменены.
  

Несмотря на то, что указанные параметры («В индексе», «В поиске», «В карте сайта») находятся визуально рядом, эти опции совершенно разные и друг с другом никак не связаны.

Добавление в индекс / индексация

Эта опция подразумевает разрешение или запрет страницы для индексации мета-тегом robots. При разрешении индексации значение равно index, follow. При запрете значение равно noindex, nofollow.

Данная опция срабатывает в момент открытия страницы каждым пользователем.

Добавление в поиск

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

Опция срабатывает в момент её изменения, мгновенно добавляя или удаляя данные из поиска.

Важный нюанс! Модуль добавляет данные в поиск стандартным способом, в т.ч. с указанием привязки к сайту, поэтому в общем случае поиск должен всегда работать как ожидается. Однако на многих сайтах поиск сделан в два этапа: на первом этапе отбираются подходящие записи из поискового индекса, а на втором этапе эти записи выводятся в каталоге - в этом случае ссылки нашего модуля не будут выведены, т.к. показ результатов поиска в каталоге подразумевает поиск только по товарам сайта. Остальные сущности (страницы, новости, статьи и т.д.) в таком случае в поиске не участвуют.

Добавление в карту сайта

Добавление в карту сайта подразумевает создание отдельного файла карты сайта (или нескольких таких файлов) для ссылок нашего модуля. Т.е. при создании карты сайта Битрикс наш модуль автоматически срабатывает и дополняет созданную карту сайта собственными данными.

В результате работы создаётся один (или несколько) файлов карты сайта, со ссылками модуля, а также в общий файл карты сайта (sitemap.xml или sitemap_index.xml) помещается ссылка на созданный файл (если файлов несколько - помещаются ссылки на все файлы).

Модуль поддерживает работу обоих штатных механизмов формирования карты сайта - старый (через «Поиск») и новый (через «Маркетинг»). Таким образом, когда Вы запускаете карту сайта, создаётся штатная карта сайта Битрикс, и в момент окончания её генерации начинает работу наш модуль.

Соответственно, опция добавления в карту сайта срабатывает на этапе генерации карты сайта.

Внимание! Несмотря на кажущуюся простоту, вывод кнопок перелинковки - самая сложная задача в модуле. Всё дело в том, что ссылки, условно, хранятся единым списком, а компонент перелинковки накладывает различные условия на их отбор для вывода. Причём нюансов отбора очень много, и многие из них сложны для понимания. Различные режимы выбора ссылок задают совершенно разные условия для их отбора. В связи с этим, рекомендуем сначала детально изучить работу с правилами и со ссылками, и только затем настраивать вывод кнопок перелинковки.

Модуль содержит компонент webdebug.seo:links (до версии 23.2.0 - webdebug:seo.links), который выводит список ссылок для перелинковки.

Обратите внимание! Это именно перелинковка модуля, т.е. ссылки с одних ссылок модуля на другие. Конечно, можно настроить и в режимах, позволяющим не привязывать отбор ссылок к текущему правилу или профилю (напр., можно настроить, чтобы в разделах выводились ссылки, привязанные к этим разделам), но возможности для этого не самые широкие.

Важно! Компонент не позволяет работать в режиме «здесь выводим вот эти ссылки, вон так выводим вон те ссылки», т.е. обычно используют один компонент, поэтому на весь каталог должна быть единая логика. Поэтому советуем выбирать один из простых и понятных режимов (напр., в режиме «Раздел»), и его донастраивать. Режим «По умолчанию» далеко не во всех случаях является наиболее подходящим.

Пример подключения компонента (режим - «Раздел»):

<?$APPLICATION->IncludeComponent(
	"webdebug.seo:links", 
	".default", 
	array(
		"COMPONENT_TEMPLATE" => ".default",
		"AJAX_PREVENT" => "Y",
		"ALLOW_CURRENT" => "Y",
		"COUNT" => "100",
		"DISPLAY_COUNT" => "N",
		"HIDE_EMPTY" => "Y",
		"JUST" => "N",
		"MODE" => "SECTION",
		"SELECTED_FIRST" => "Y",
		"SORT_FIELD_1" => "ID",
		"SORT_FIELD_2" => "ID",
		"SORT_ORDER_1" => "ASC",
		"SORT_ORDER_2" => "ASC",
		"RULE_ID" => "",
		"FILTER_NAME" => "",
		"LINK_SECTION" => "N",
		"SECTION_ID" => $arResult["VARIABLES"]["SECTION_ID"],
		"JUST_FILTER_LINKS" => "N",
		"URL_GROUP" => "N",
		"COLLAPSE" => "Y",
		"COMPOSITE_FRAME_MODE" => "A",
		"COMPOSITE_FRAME_TYPE" => "AUTO"
	),
	false
);?>

Компонент имеет достаточно широкие возможности вывода ссылок.

Основное, что следует иметь в виду - все (без исключений) SEO-ссылки модуля хранятся в одной таблице в виде одного общего списка, задача данного компонента - вывести эти ссылки, используя фильтр. А Ваша задача - всего лишь правильно настроить этот фильтр (учитывая профиль, раздел, правило - в зависимости от поставленной задачи), т.е. выбрать один из предоставленных режимов получения ссылок.

Поэтому, почти каждая опция в настройках компонента перелинковки либо смягчает, либо ужесточает требования к отбору ссылок, причём некоторые опции в некоторых случаях могут привести к тому, что ссылки не будет выведены вообще. Не изменяйте опции, назначение которых Вы не понимаете.

Режим (параметр «Источник ссылок», MODE) определяет, откуда модулю следует выбрать ссылки для вывода. Режим «По умолчанию» подразумевает использование ссылок из связанных (по полю «Перелинковка») правил, а если правила не привязаны - из текущего правила.

Текущее правило определяется двумя способами: его можно явно указать в настройках компонента (параметр «ID правила», RULE_ID), а если оно не указано, то определяется из текущей ссылки (если текущая страница является страницей, сгенерированной модулем).

Опция «Работа только при найденной ссылке» позволяет остановить работу компонента вывода ссылок, если текущая странице не является страницей, сгенерированной модулем.

• LINK_SECTION - включает/отключает учёт данного функционала в компоненте (Y / N),
• LINK_SECTION_ID - ID раздела, для которого следует проверить привязку ссылок (число),
• LINK_SECTION_STRICT - строгий режим, при котором правила с незаполненными привязками не участвуют в выборке (Y / N).

• LINK_SECTION_PARENTS - учёт родительских разделов при определении ссылок перелинковки (Y/N),
• LINK_SECTION_IBLOCK_ID - ID инфоблока (число).

Учёт родительских разделов работает по следующему принципу: для текущего раздела (LINK_SECTION_ID) модуль может определяет всех родителей (как раз для этого используется LINK_SECTION_IBLOCK_ID) и отбирает те ссылки, в правиле которых указан или сам раздел, или его родители.

Таким образом, если у Вас есть, например, раздел «Обувь», в котором 10 других подразделов - вместо того чтобы отмечать все 10 подразделов, достаточно один раз отметить раздел «Обувь».

Прежде всего, речь пойдёт о компоненте webdebug:seo.links, если он у Вас ещё не установлен - пожалуйста, установите. Дальнейшее описание касается настроек данного компонента.

Прежде всего убедитесь, что для ссылок сгенерированы названия - ведь именно они и выводятся в виде тегов.

Для начала необходимо определиться с режимом вывода ссылок (параметр «Источник ссылок»). Доступны следующие варианты.

• по умолчанию - модуль определяет текущее правило (по текущей ссылке, или если правило явно указано в параметрах компонента), и если в правиле задана перелинковка - использует её для получения ссылок из всех прикреплённых в перелинковке правил, иначе использует ссылки текущего же правила,
• поле «перелинковка» - модуль определяет текущее правило (по текущей ссылке, или если правило явно указано в параметрах компонента) и использует привязанные правила перелинковки для поиска в них ссылок,
• правило - модуль определяет текущее правило (по текущей ссылке, или если правило явно указано в параметрах компонента) и показывает из него ссылки,
• раздел - модуль определяет текущий раздел (по текущей ссылке, или если раздел явно указан в параметрах компонента), и показывает все ссылки, относящиеся к данному разделу,
• профиль - модуль определяет текущий профиль (по текущей ссылке, или если профиль явно указан в параметрах компонента), и показывает все ссылки, относящиеся к данному профилю.

Соответственно, если вывод ссылок не работает, одной из причин может стать неверно указанный параметр «Источник ссылок». При этом, если идентификаторы раздела (профиля, правила) указаны в подключении компонента - проверьте указанные параметры.

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

Наконец, проверьте остальные параметры компонента, которые могут влиять на выборку ссылок:

• Работа только при найденной ссылке - ссылки будут показываться только если текущая страница является настроенной страницей для SEO умного фильтра,
  
• Скрывать ссылки без названия - будут показаны только ссылки с непустым полем «Название».

Кроме того, есть нюанс при использовании в правилах перелинковки поля «Разделы для показа» - если Вы хотите чтобы ссылки показывались на страницах всех разделов (даже для тех, которых не создано ни одного правила), то следует использовать режим «Произвольный», т.к. остальные режимы предполагают работу при найденном или заданном правиле, т.е. предполагают что с открытым разделом ассоциирована о какое-либо правило перелинковки. Также, в этом случае может потребоваться отметить галочку «Строгий режим раздела перелинковки», иначе ссылки будут выведены также на всех дочерних разделах.

Приведённые макросы - #Z_PRODUCTS_COUNT.VALUE#, #Z_PRICE_1_MIN.VALUE# - #Z_PRICE_1_MAX.VALUE# - это «умные» поля, которые в момент генерации ссылок не заменяются и остаются как есть, а заменяются в момент вывода на странице, т.е. эта замена срабатывает на каждом хите. Соответственно, данные в этих полях всегда актуальны, в отличие от сгенерированных заранее данных. Например, поле #X_PRODUCTS_COUNT.VALUE# - оно определяет количество товаров в разделе в момент генерации, а если после генерации в раздел добавились новые товары - число товаров останется старым до очередной генерации.

«Умные» поля не поддерживаются в перелинковке, т.к. перелинковка всего лишь выполняет отбор ссылок, без дополнительных преобразований макросов в них.

Кроме того, «умные» поля рассчитаны на одиночное выполнение на странице, поэтому если бы в компоненте перелинковки и была поддержка «умных» полей, это была бы огромная нагрузка на сервер, особенно на больших каталогах: т.к. по каждой ссылке приходилось бы сначала запросом определять набор условий для фильтра, а следующим (очень тяжёлым!) запросом - проверять количество товаров по этому фильтру.

Поэтому, «умные» поля работают только на странице конкретной ссылки. Поэтому, использовать такие макросы в поле «Название ссылки» нельзя.

Параметр «Разделы для показа» управляет тем, в каких разделах могут быть показаны ссылки из данного правила в перелинковке.

Самое главное что нужно всегда помнить - это дополнение к остальным параметрам, оно может лишь ещё более уменьшить отбор ссылок. Т.е. если у Вас перелинковка сейчас ничего не выводит, то этот параметр не сможет решить проблему. А вот если перелинковка исправно выводит ссылки, то данный параметр может привести к тому, что ссылки не будут выводиться - всё зависит от правильной настройки.

Вся идея данной опции очень проста: она позволяет вывести ссылки с привязкой к выбранным разделам. Например, если Вы создали правило генерации ссылок, и знаете, что ссылки из него должны показываться только в каком-то одном (или двух) разделах, то данная опция Вам поможет.

Как пользоваться?

Важно понимать, что если Вы выбрали разделы в данном параметре - это ещё даже не полдела, никаких изменений не увидите. Необходимо в настройках компонента перелинковки заполнить необходимые параметры.

#COMPONENT_PARAMETERS #

Отмечаем галочку «Учитывать выбранные разделы перелинковки в правилах»,

В поле «ID инфоблока для раздела перелинковки» указывает ID инфоблока, в котором модуль будет искать нужный раздел (ниже опишем подробно),

Указываем основной параметр - «ID раздела перелинковки» - здесь должен быть указан раздел, относительно которого будет проверяться привязки. Т.е. если Вы в правиле (в параметре «Разделы для показа») выбрали раздел «Телевизоры», и хотите, чтобы ссылки выводились, значит здесь должен быть указан ID раздела «Телевизоры».

Важно! Конечно, указывать ID раздела в визуальном режиме - это неправильно, потому что в реальных условиях ID раздела почти во всех случаях - это текущий показываемый раздел сайта. Поэтому, ID раздела нужно указывать в коде подключения. Например, так (этот код на Вашем сайте может не работать, т.к. ID раздела может быть не в $arCurSection["ID"]):

<?$APPLICATION->IncludeComponent("webdebug:seo.links", "", Array(
	"LINK_SECTION" => "Y",
	"LINK_SECTION_IBLOCK_ID" => $arParams["IBLOCK_ID"],
	"LINK_SECTION_ID" => $arCurSection["ID"],
);?>

В таком случае визуально эти параметры будут отображаться в настройках компонента таким образом:

Чего мы добились?

Указанными настройками мы включили функционал по привязанным разделам. И теперь будут показываться только те ссылки, в правилах у которых выбран данный раздел.

Например, мы создали правило генерации ссылок для раздела «Мониторы», в нём будут генерироваться ссылки по брендам (например, мониторы Samsung, мониторы LG и т.д.). И мы хотим, чтобы эти ссылки показывались только в разделе с компьютерами (системными блоками), чтобы пользователи после выбора компьютера перешли к выбору монитора. Тогда мы в правиле отмечаем раздел «Системные блоки». Если указанные выше настройки сделаны, то эти ссылки мы будем видеть только в разделе «Системные блоки».

Строгий режим раздела перелинковки

Опция «Строгий режим раздела перелинковки» позволяет не использовать ссылки из правил, в которых разделы не привязаны. Т.е. если в правиле генерации не заполнено поле «Разделы для показа», то при включённом строгом режиме ссылки этого правила вообще нигде не будут выводиться.

Т.е. в таком случае действует логика «выводим только там, где мы выбрали»

Учитывать родительские разделы

Параметр «Учитывать родительские разделы» позволяет вывести в текущем разделе ссылки из правил, в которых выбран не только текущий раздел, но и его родительские разделы.

Например, у нас в каталоге есть раздел «Бытовая техника» - «Телевизоры». В правиле генерации мы выбрали привязку перелинковки к разделу «Бытовая техника».

Теперь, находясь в разделе «Бытовая техника» мы видим ссылки из данного правила, а при переходе в раздел «Телевизоры» не видим их.

Включаем опцию «Учитывать родительские разделы», и видим, что ссылки теперь показываются. Это работает так: модуль видит, что задан раздел «Телевизоры» (мы в нём находимся и его ID передан в параметр LINK_SECTION_ID), модуль определяет все его родительские разделы, и теперь ищет ссылки правил, в привязках которых есть хотя бы один из двух разделов - «Бытовая техника» или «Телевизоры».

Пара примеров:

Группировка ссылок доступна с версии 22.16.0.

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

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

Всё, что требуется для использования группировки - в правилах прописать названия и коды групп (названия и код - произвольные значения; код группы является обязательным, при отсутствии кода ссылки из правила считаются несгруппированными), и в настройках компонента отметить галочку «Группировать ссылки». Перегенерация не требуется. При этом, должен использоваться обновлённый шаблон (шаблон из модуля ниже версии 22.16.0 не будет поддерживать группировку - поэтому, если Вы кастомизировали шаблон, группировка не будет работать).

Ссылки без группы будут выведены в последнюю очередь, без заголовка.

Нет. Не поможем.

Дело в том, что нам для настройки необходимо знать в подробностях то, как следует настроить. Эти подробности можете знать только Вы. А если Вы их знаете - значит, Вы и самостоятельно можете настроить. Т.к. настройка - это просто настройка общих параметров, выбор нужного режима, настройка дополнительных параметров для выбранного режима.

Поэтому, настраивать Вам придётся самостоятельно, предварительно изучив режимы выбора ссылок и параметры для режимов.

При этом на все возникающие вопросы с удовольствием ответим.

Наш модуль умеет выполнять два вида редиректов:

1. базовые - редиректы, относящиеся к домену и сайту в целом. На текущий момент модуль умеет выполнять 4 типа редиректов данного вида:
   1. редирект из http:// на https://,
   2. редирект с www.сайт.ру на сайт.ру (и наоборот),
   3. редиректы c сайт.ру/index.php на сайт.ру,
   4. редиректы с сайт.ру/раздел на сайт.ру/раздел/
2. произвольные - с любой страницы сайта на любую другую страницу сайта.

Для настройки перейдите в раздел «SEO - мастер» - «Сайты», и для нужного сайта выполните требуемое действие. Это можно сделать двумя способами:

1. из контекстного меню на строке сайта (нажать на кнопку с тремя линиями или просто щёлкнуть правой кнопкой мыши) - для каждого сайта отдельно,
2. отметив нужные сайты и выбрав общее действие под списком - это действие сразу для всех сайтов.

Перейдите на страницу «SEO - мастер» - «Редиректы». Нажмите кнопку «Добавить редирект». В форме укажите три обязательных поля:

1. привязка к сайту,
2. старый адрес - который нужно перенаправить на другой,
3. новый адрес - на который будет перенаправлять текущий редирект.

/catalog/?SECTION_CODE=futbolki

/catalog/futbolki/

Вы можете указать тип редиректа, однако в SEO всегда применяется только редирект с кодом 301.

Также, Вы можете отметить опцию «Использовать RegExp» - это активирует другой режим работы редиректа, при котором Вы можете использовать регулярные выражения. Это может быть полезно, когда у Вас для какого-то случая множество страниц, но редиректы можно объединить по какому-то алгоритму перестановки в строке. Например, у Вас были адреса вида
/catalog/?SECTION_CODE=kurtki
а после модернизации сайта адреса стали вида
/catalog/kurtki/

В таком случае вместо того, чтобы добавлять десятки и сотни редиректов для всех разделов, достаточно будет добавить один редирект с регулярным выражением. В поле «Старый адрес» укажите
^/catalog/\?SECTION_CODE=(\w+)$
а в поле «Новый адрес» так:
/catalog/$1/

И после такой замены, например, будут работать все такие редиректы:

/catalog/?SECTION_CODE=futbolki => /catalog/futbolki/
/catalog/?SECTION_CODE=botinki =? /catalog/botinki/
и т.д.

Для использования регулярных выражений в редиректе, отметьте опцию «Использовать RegExp» - это активирует другой режим работы редиректа, при котором Вы можете использовать регулярные выражения. Это может быть полезно, когда у Вас для какого-то случая множество страниц, но редиректы можно объединить по какому-то алгоритму перестановки в строке. Например, у Вас были адреса вида
/catalog/?SECTION_CODE=kurtki
а после модернизации сайта адреса стали вида
/catalog/kurtki/

В таком случае вместо того, чтобы добавлять десятки и сотни редиректов для всех разделов, достаточно будет добавить один редирект с регулярным выражением. В поле «Старый адрес» укажите
^/catalog/\?SECTION_CODE=(\w+)$
а в поле «Новый адрес» так:
/catalog/$1/

И после такой замены, например, будут работать все такие редиректы:

/catalog/?SECTION_CODE=futbolki => /catalog/futbolki/
/catalog/?SECTION_CODE=botinki =? /catalog/botinki/
и т.д.

Общий принцип работы с каноническими адресами в нашем модуле следующий:

1. прежде всего, рекомендуем отключить все функции сайта, задающие канонические адреса страницам сайта - иначе возможны конфликты и «странные» ситуации,
   
2. включите в настройках модуля опцию «Включить автоматическую установку»,
3. проверьте работу автоматических канонических адресов на всех страницах сайта,
4. в настройках модуля включите опцию «Разрешить установку через php-код» и в компонентах списка товаров (bitrix:catalog.section и др) и карточки товара (bitrix:catalog.element, bitix:catalog.item и др) разместите нужный код: https://www.webdebug.ru/marketplace/webdebug.seo/?tab=faq#36936,
5. проверьте работу канонических адресов на страницах списка товаров и карточки товара,
6. для отдельных страниц может потребоваться особая настройка, для этого перейдите в меню «Канонические адреса» и добавьте нужные правила,
7. проверьте работу канонических адресов на заданных страницах.

Задать канонические адреса для страницы можно по-разному.

Стандартный способ 1С-Битрикс, не относящийся к нашему SEO-модулю:

$APPLICATION->setPageProperty('canonical', 'ссылка');

Установка через модуль (модуль должен быть подключен):

\WD\Seo\Canonical::setCustomCanonical('ссылка');

При этом метод setCustomCanonical в качестве второго параметра принимает флаг приоритета - true или false. Флаг true означает повышенный приоритет. Модуль в течение выполнения всей страницы собирает запросы через указанный метод, и после этого задаёт странице последний заданный канонический адрес.

Таким образом на странице может работать несколько вызовов, например, на странице сначала задаётся канонический адрес из фильтра (с приоритетом), при условии что он применён, а далее - из списка товара (без приоритета), таким образом canonical будет установлен из фильтра.

Пример установки из списка товаров:

if(\Bitrix\Main\Loader::includeModule("webdebug.seo")){
  \WD\Seo\Canonical::setCanonicalForSection(SITE_ID, $arParams["IBLOCK_ID"], $arResult["ID"]);
}

if(\Bitrix\Main\Loader::includeModule("webdebug.seo")){
  \WD\Seo\Canonical::setCanonicalForElement(SITE_ID, $arParams["IBLOCK_ID"], $arResult["ID"]);
}

Пример установки канонического адреса из фильтра:

if(\Bitrix\Main\Loader::includeModule('webdebug.seo')){
  if(strpos($arResult['FILTER_URL'], '/filter/clear/apply/') === false){
    \WD\Seo\Canonical::setCustomCanonical($arResult['FILTER_URL'], true);
  }
}

Прежде всего напомним, что в Битриксе канонические адреса всегда должны задаваться таким способом:

$APPLICATION->setPageProperty("canonical", "ссылка");

На теги canonical, добавленные вручную, модуль не смотрит совершенно, для модуля эти теги не существуют.

Далее, важно отметить, что канонические адреса модуль устанавливает на событии onBeforeEndBufferContent, т.е. практически в конце выполнения страницы.

Если на странице был задан другой канонический адрес стандартным способом, он будет перезаписан.

Задать канонический адрес для вывода можно методом

\WD\Seo\Canonical::setCustomCanonical("ссылка");

При этом данный метод вторым аргументом может принимать приоритет - true или false.

Общая схема работы с данным модулем следующая: на странице можно сколько угодно раз выполнить данный метод, и конечным результатом будет последний выполненный (если использовался приоритет - то последний выполненный с приоритетом). И в конце выполнения страницы подготовленный канонический адрес будет выведен в тег canonical.

Общий принцип автоматических канонических адресов предельно прост: модуль при открытии конкретной страницы поисковиком или пользователем удаляет из адреса все GET-параметры кроме важных (задаются в настройках модуля), и получившийся адрес ставит в качестве канонического.

В результате, если в адресе указаны какие-либо лишние параметры (а это бывает очень часто и это совершенно нормально), то модуль сообщает поисковикам правильный адрес, без учёта этих параметров.

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

При генерации собственных страниц SEO для умного фильтра может возникнуть необходимость не индексировать страницы, содержащие, к примеру, /filter/property-is-value/apply/.

Кроме того, даже без настройки SEO для умного фильтра может возникнуть желание убрать из поиска страницы вида /filter/clear/apply/ (эти страницы появляются при нажатии кнопки сброса фильтра).

Модуль позволяет для таких страниц добавить канонический адрес, указывающий на основной раздел, для этого перейдите на страницу «Канонические адреса», и добавьте новый канонический адрес:

• Реальный адрес: /filter/.*?/apply/

• Канонический адрес: /

• Использовать RegExp: да

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

В случае, если необходимо убрать только /filter/clear/apply/ в поле «Реальный адрес» укажите /filter/clear/apply/.

Все SEO-ссылки модуля (и сгенерированные SEO для умного фильтра, и добавленные вручную) прописывают canonical сами на себя, т.к. эти ссылки создаются для продвижения, и указывать с них канонические адреса на какие-либо другие страницы - неправильно.

Модуль, начиная с версии 22.6.0 (от 21.04.2022) добавляет ЧПУ для постраничной навигации! Данный функционал работает автоматически, настраивать htaccess и urlrewrite не требуется!

Теперь вместо некрасивых адресов вида /catalog/section/?PAGEN_1=2 вы можете настроить практически любой вариант, который Вам необходим, например, /catalog/section/page2/.

Возможен даже вариант /catalog/section/2/, но только если на Вашем сайте не используются адреса, в которых на конце таким же образом могут фигурировать числа (в противном случае такие страницы не будут работать, т.к. модуль будет считать их постраничной навигацией).

Модуль позволяет выбрать один из трёх режимов и донастроить его под собственные требования. Настроек достаточно много. При этом, если каких-то настроек недостаточно - пишите нам, добавим.

Примеры вариантов настроек в зависимости от режима:

1. Режим 1 - /catalog/razdel/page2/
   • /catalog/razdel/page2/
     
   • /catalog/razdel/page-2/
   • /catalog/razdel/2/
   • /catalog/razdel/page:2/
   • /catalog/razdel/stranica-2/
     
   • /catalog/razdel/2-stranica/
     
   • /catalog/razdel/page=2/
     
2. Режим 2 - /catalog/razdel/page2
   • /catalog/razdel/page2
     
   • /catalog/razdel/page-2
   • /catalog/razdel/2
   • /catalog/razdel/page:2
   • /catalog/razdel/stranica-2
     
   • /catalog/razdel/2-stranica
     
   • /catalog/razdel/page=2/
3. Режим 3 - /catalog/razdel/?page=2
   • /catalog/razdel/?page=2
     
   • /catalog/razdel/?p=2
     
   • /catalog/razdel/?stranica=2
     

Важную роль играет правильно указанный параметр «Имя параметра PAGEN». В нём нельзя просто указать, например "page-2", т.к. 2 - это только частный случай, а если страница будет 3? Номер страницы заменяется на символ "@", поэтому указывать нужно так: page-2 - тогда модуль правильно поймёт как сгенерировать название параметра для нужной страницы.

На данный момент модуль работает в тестовом режиме (бета-версия), на некоторых сайтах могут быть проблемы в работе данного функционала, особенно при использовании нестандартной постраничной навигации.

Также, важный нюанс: все страницы должны работать только через первый индекс постраничной навигации (т.е. PAGEN_1, но не PAGEN_2). На самом деле, индексы выше единицы встречаются сейчас только на сайтах, где что-то некорректно работает. Т.е. если на Вашем сайте иногда появляется PAGEN_2, PAGEN_3, значит где-то имеются проблемы, и их необходимо решать.

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

1. замена в исходном коде страницы ссылок с ?PAGEN_1=2 на, например, /page-2/ - т.е. при открытии страницы ссылки в постраничной навигации мы видим уже как /page-2/
2. подмена адресов - при открытии страницы с номером страницы в виде /page-2/ модуль, используя собственные механизмы, указывает сайт, что следует открыть страницу с параметром ?PAGEN_1=2.

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

В случае, если на Вашем сайте адреса работают со слешем на конце (а это большинство случаев), опция «Оставлять слеш после преобразования» должна быть включена.

По умолчанию в постраничной навигации раздела используются стандартные адреса. Например, если вы в SEO для умного фильтра создали для страницы /catalog/televizory/filter/brand-is-lg/apply/ красивый адрес /catalog/televizory/lg/, то, находясь на странице этого «красивого» адреса, в постраничной навигации Вы продолжите видеть ссылки вида /catalog/televizory/filter/brand-is-lg/apply/?PAGEN_1=2.

Это происходит потому, что модуль для страницы с «красивым» адресом устанавливает реальный адрес, чтобы обеспечить её работоспособность, поэтому и постраничная навигация видит реальный адрес.

Обновление модуля 22.9.3 решает данный вопрос. После обновления всё, что требуется - прописать код перед подключением компонента bitrix:catalog.section (обычно это выполняется в файле section.php или section_vertical.php или section_horizontal.php шаблона компонента bitrix:catalog):

if(\Bitrix\Main\Loader::includeModule('webdebug.seo')){
	\WD\Seo\Page::fixCatalogSectionBaseUrl($arParams);
}

Внимание! Не забудьте проверить, что в дальнейшем подключении компонента используются параметры PAGER_BASE_LINK_ENABLE и PAGER_BASE_LINK, например так:

"PAGER_BASE_LINK_ENABLE" => $arParams["PAGER_BASE_LINK_ENABLE"],
"PAGER_BASE_LINK" => $arParams["PAGER_BASE_LINK"],

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

Данная проблема связана, скорее всего, с тем, что для постраничной навигации у Вас используется не PAGEN_1, а, например, PAGEN_2 или PAGEN_3.

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

Например, такая проблема часто бывает в функционале поиска (в т.ч. в готовых шаблонах), т.к. перед выводом списка подключаются другие компоненты, которые используют постраничную навигацию, поэтому компоненте списка использует индекс постраничной навигации отличный от первого, и поэтому стандартный функционал нашего модуля не работает.

Лучшее решение данного вопроса - исправление проблемы, чтобы постраничная навигация была PAGEN_1. А если это сложно (или нецелесообразно) - то модуль содержит отдельный параметр, позволяющий для отдельных страниц учитывать это:

Данный вариант означает, что для всех страниц внутри раздела /search/ модуль должен использовать PAGEN_3 вместо стандартного PAGEN_1, и тогда всё будет работать.

Кроме того, для программистов, есть относительно лёгкий способ исправления на сайте, чтобы вместо PAGEN_2, PAGEN_3 (и т.д.) использовался PAGEN_1. Принцип такой: нужно найти на странице начало кода, где компонент или некий кусок кода, который увеличивает индекс постраничной навигации (но в котором она не используется), и задать перед этим:

$GLOBALS['NavNum'] = 10;

а после этого:

$GLOBALS['NavNum'] = null;

Т.е. перед вызовом "лишнего" компонента, использующего постраничную навигацию, нужно задать заведомо большое значение индекса постраничной навигации, а после него - сбросить его в null, таким образом следующий компонент будет считать что постраничной навигации на странице пока не было, и будет использовать PAGEN_1, тогда функционал модуля должен работать.

Таким образом, мы меняем порядок индексов. Лишние будут использовать индекс 10, 11, и т.д. А после них мы обнуляем индекс, и наш компонент будет использовать индекс 1. В результате, достигается нужный эффект.

Конечно же, с точки зрения хорошего программиста, это "костыль". Правильное исправление проблемы значительно сложнее, а иногда исправление требует значительного изменения логики работы скрипта или компонента, что не всегда возможно. Поэтому, нужно выбирать - либо правильное и сложное решение, либо лёгкий костыль.

Разделы-ссылки - это новый функционал SEO-модуля, позволяющий для имеющихся разделов создать дополнительные разделы, которые будут указывать на ранее созданные разделы, при этом товаров в них не будет.

В качестве примера: сайт спортивных товаров. Нам нужно создать раздел «Детские трёхколёсные велосипеды». При этом на сайте имеются следующие большие разделы:

• Велосипеды
• Детские товары

В каком из них создать новый раздел с трёхколёсными велосипедами? Во многих случаях необходимо добавить сразу в оба раздела (возможно, их даже больше чем два), чтобы в меню раздел «Детские трёхколёсные велосипеды» были сразу и в «Велосипедах» и в «Детских товарах». Но в этом случае возникает много сложностей, которые решить либо невозможно, либо дорого.

Другой пример: раздел «Карты памяти» на сайте бытовой техники: он находится и в разделе «Аксессуары для телефонов», и в разделе «Фото- и видео- техника».

Стандартного функционала Битрикса здесь нет, т.к. при такой схеме разделов в лучшем случае что можно придумать - это все товары внутри этих разделов привязывать к обоим разделам сразу. Очевидно, что это неудобно: если менеджер забудет привязать товар к обоим разделам, или эта привязка слетит по какой-то причине, пользователь при открытии раздела увидит только часть товаров. Кроме того, для SEO это плохо, т.к. вес одной страницы делится на две.

Но даже если привязать все товары к обоим разделам сразу, при необходимости добавления этого раздела в дополнительное место (например, в раздел «Летний спорт»), придётся тратить много времени на привязку всех товаров к дополнительному разделу.

Кроме того, если Ваш каталог загружается из 1С или из внешних источников, организовать такой подход просто нереально.

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

Принцип работы прост: в настройках модуля для каждого инфоблока необходимо создать отдельное свойство (свойства - отдельные для каждого из сайтов), и в нём указывать либо прямую ссылку на нужный раздел (например, /catalog/velosipedy/), либо числовой идентификатор раздела, на который он будет указывать. В итоге получится такая схема: раздел «Детские трёхколёсные велосипеды» физически находится в разделе «Велосипеды», а дополнительные разделы, созданные в разделах «Детские товары» и «Летний спорт», будут являться лишь ссылками, и в них необходимо указать ID раздела «Велосипеды» (или его адрес: /catalog/velosipedy/). Открытие таких ссылок будет перенаправлять пользователей на раздел с детскими велосипедами внутри раздела со всеми велосипедами.

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

Важно!

1. Не создавайте никаких свойств вручную - это делается в настройках модуля, нажатием кнопки напротив нужного свойства. И всё.
2. Свойства - имеются в виду свойства раздела. Не путайте со свойствами товаров!
3. Разделы-ссылки не могут работать как обычные разделы, с них будет выполняться редирект. Поэтому не настраивайте один работающий раздел как ссылку на другой работающий раздел - первый перестанет работать.

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

При активированном функционале каждое сохранение раздела-ссылки с указанным адресом (или ID раздела) сохраняет эти данные в таблице модуля. И затем, при открытии любой страницы модуль получает все ссылки и для каждой меняет все совпадения в коде страницы.

Таким образом, чтобы изменения применялись, необходимо чтобы галочка «Включить разделы-ссылки» была включена (вариант когда опция отключается на время заполнения данных в разделах - невозможен), т.е. сначала галочка включается, потом заполняются ссылки в разделах.

Вы можете использовать любой из трёх вариантов указания ссылки, которая будет открываться на сайте:

• прямая ссылка на раздел (пример: /catalog/futbolki/)
• ID раздела (пример: 123) - в таком случае модуль по указанному ID раздела автоматически определит его адрес
• ID любой SEO-ссылки - укажите со знаком @ (пример: @123) - в таком случае модуль автоматически определит адрес SEO-ссылки (ссылки, которую можно открыть на странице «Все ссылки» в модуле).

Анализатор запросов - универсальный инструмент, который предоставляет статистику посещаемости сайта. В отличие от таких сервисов как Яндекс.Метрика и Google-аналитика, данный инструмент собирает информацию, в первую очередь, о роботах, в т.ч. поисковых роботах.

Используя анализатор, Вы можете увидеть, как часто к сайту обращаются различные роботы Яндекса (основной и мобильный роботы, роботы запросы картинок и видео, роботы Маркета, Метрики и другие), Google, Mail.ru и другие.

При этом, информация по каждому из сайтов доступна, в том числе, по каждому из доменов отдельно (в большинстве случаев разные домены - это разные регионы). Таким образом, можно понять, по каким регионам какие поисковики как много запросов совершают.

Также имеется статистика по наиболее частых роботам - это может пригодиться для общего понимания, того, какие роботы обращаются к сайту чрезмерно часто (чтобы либо заблокировать, если это совершенно ненужный робот, либо ограничить его активность через robots.txt, если это возможно).

Модуль анализирует посещения только по User-Agent, это текстовая строка-идентификатор, которую передаёт браузер при обращении к сайту.

Например, Google при обращении сообщает "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)".

Яндекс сообщает "Mozilla/5.0 (compatible; YandexBot/3.0; +http://yandex.com/bots)".

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

Модуль все такие обращения фиксирует как обращения от пользователей. Сервисы аналитики, например, Яндекс.Метрика, работает на других принципах - они анализируют всю информацию о хите, включая отслеживание его активности на странице, поэтому такие сервисы могут более точно отличать пользователей от замаскированных роботов. Поэтому, если модуль посчитал что обычных пользователей всего 100, то Яндекс.Метрика может сообщить, что пользователей, например, всего 50, или даже 20, т.к. Яндекс более точно отсеивает таких роботов.

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

В Битриксе используется мультисайтовость, и она имеет свои нюансы.

Например, административный раздел, фактически, является отдельным сайтом, поэтому все запросы в админку (в т.ч. AJAX-запросы из публичной части к скриптам внутри папки /bitrix/) не учитываются как запросы к сайту.

И это даже в том случае, когда мультисайтовость не используется. Т.е. если на Вашей платформе Битрикс всего один сайт, а публичная часть выполняет AJAX-запросы, например, в /bitrix/templates/ или в /bitrix/components/ - то сайт не будет определён, т.к. фактически эти запросы выполняются в админку.

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

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

Основное, что нужно знать - модуль выполняет обработчик OnGetAnalyzerMetrics для получения дополнительных диаграмм, в качестве единственного аргумента передаётся (по ссылке) массив встроенных графиков. Поэтому, если хотите добавить свой - просто добавьте в этот массив свой элемент наподобие уже существующих.

Новый элемент должен добавляться в массив со своим кодом (только латинские символы и цифры), а в самом массиве должны быть следующие данные: NAME (название), GROUP (группа - GENERAL, SEARCHER, USERS, GLOBAL или CUSTOM), SORT (индекс сортировки, по умолчанию 1000), COLOR (CSS-цвет диаграммы), и CALLBACK - функция, принимающая три аргумента: $strSiteId, &$intCountYes, &$intCountAll, где $strSiteId - это двузначный идентификатор сайта, $intCountYes - число подходящих элементов, $intCountAll - общее число элементов для диаграммы [для каждой из групп заранее высчитывается дефолтное значение, поэтому можно его не менять].

Пример обработчика для добавления графика для Яндекс.Турбо:

addEventHandler('webdebug.seo', 'OnGetAnalyzerMetrics', function(&$arMetrics){
	$arMetrics['YANDEX_TURBO'] = [
		'GROUP' => 'CUSTOM',
		'SORT' => 1000,
		'NAME' => 'Запросы Яндекс.Турбо',
		'COLOR' => 'blue',
		'CALLBACK' => function($strSiteId, &$intCountYes, &$intCountAll){
			$intCountYes = static::getCount($strSiteId, ['=CLI' => 'N', '=BOT_CODE' => 'YandexTurbo']);
		}
	];
});

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

Блокировка работает легко. Нужно в настройках модуля для выбранного сайта открыть раздел «Индексация» - «Блокировка роботов», отметить галочку «Блокировать роботов», и в текстовом поле «Список роботов для блокировки» указать (каждого - на отдельной строке) список ботов для блокировки.

• Mozilla/5.0 (compatible; SemrushBot/7~bl; +http://www.semrush.com/bot.html)
• Mozilla/5.0 (compatible; MJ12bot/v1.4.8; http://mj12bot.com/)
  
• Mozilla/5.0 (compatible; AhrefsBot/7.0; +http://ahrefs.com/robot/)
  
• Mozilla/5.0 (Linux; Android 7.0;) AppleWebKit/537.36 (KHTML, like Gecko) Mobile Safari/537.36 (compatible; PetalBot;+https://webmaster.petalsearch.com/site/petalbot)
  

• SemrushBot
• MJ12bot
  
• AhrefsBot
  
• PetalBot
  

Именно эти четыре строки с краткими названиями роботов и следует указать в поле «Список роботов для блокировки».

При этом доступна возможность указать HTTP-код для блокировки, и даже текст ответа, например: "Асталависта, #BOT#!" - при блокировке бот увидит сообщение "Асталависта, MJ12bot!".

Регионы - это новый функционал в модуле, который позволяет как выбирать пользователям свой регион, так и продвигать свой сайт в разных регионах.

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

На данный момент в модуле доступны четыре совершенно разных режима работы регионов:

1. на поддоменах, например: krasnodar.webdebug.ru, khavarovsk.webdebug.ru,
2. на разных доменах, например: krasnodar.webdebug.ru, webdebug-khabarovsk.ru,
3. на одном домене (виртуальные разделы), например: webdebug.ru/krasnodar/, webdebug.ru/khabarovsk/,
4. на одном домене без изменения адреса (просто выбор города для пользователя).

Режим «Поддомены для каждого города» - классический вариант, который отличается понятной логикой работы. Для обеспечения работы потребуется всего лишь настроить автоматическую адресацию всех поддоменов на основной домен. Т.е. если сайт работает на домене site.ru, требуется настроить сразу все поддомены (*.site.ru) на тот же сайт.

Режим «Домены для каждого города» - вариант, подходящий для небольшого числа городов, когда для каждого города используется свой домен (можно указывать также поддомены). Дополнительная настройка не требуется.

Особого рассмотрения заслуживает режим «Виртуальные разделы». Волшебство нашего модуля в том, что для поддержки такого режима в общем-то ничего не требуется. Хотя в разных случаях может потребовать донастройка отдельных нюансов, но в общем случае всё должно работать полностью автоматически. Данный функционал совершенно уникален, не имеет аналогов. ВНИМАНИЕ! Поддержка многосайтовости на одном домене - лишь частичная! Некоторые возможности недоступны. В частности, robotx.txt - он логически должен объединять все robots.txt и sitemap.xml каждого из вложенных сайтов, но такой возможности в модуле нет.

Режим «Без изменения адреса» - простейший, можно сказать примитивный. Он не изменяет адреса. Служит только для предоставления пользователям возможность выбора города.

Каждый режим имеет свои настройки, позволяющие подстроить работу модуля под Вашу задачу.

Начало работы

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

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

При переходе к списку регионов в инфоблоке в подменю кнопки «Добавить город» есть возможность экспорта и импорта регионов.

На данный На данный момент модуль предоставляет одну базу городов, распределённую по субъектам/регионам России, Вы можете её загрузить и использовать, подкорректировав данные. А можете создать свою базу с нуля. Для каждого города необходимо указание названия и кода, желательно указание координат для определения местоположения средствами браузера. момент модуль предоставляет одну базу городов, распределённую по субъектам/регионам России, Вы можете её загрузить и использовать, подкорректировав данные. А можете создать свою базу с нуля. Для каждого города необходимо указание названия и кода, желательно указание координат для определения местоположения средствами браузера.

На сайте необходимо разместить компонент webdebug.seo:regions.link, это ссылка, в которой указан текущий город, и при нажатии на которую открывается всплывающее окно с выбором город (всплывающее окно реализуется компонентом webdebug.seo:regions.popup, но его вручную подключать не нужно - это делает модуль, при AJAX-запросе из указанного ранее компонента).

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

Единственный нюанс, на который стоит обратить внимание - подключение jQuery. По умолчанию, модуль подключает на сайте jQuery версии 3, это управляется в настройках модуля в разделе «Разное» (для каждого сайта отдельно).

Если в Вашем случае библиотека jQuery на сайте уже подключена, выберите вариант «Не подключать автоматически».

После размещения компонента webdebug.seo:regions.link и при корректно подключенном jQuery на сайте отображается ссылка, в которой указан текущий определённый город (как определяется - ниже), по нажатию на ссылку открывается всплывающее окно выбора региона.

Как модуль определяет город

Модуль всегда определяет регион автоматически, а если пользователь ранее вручную выбрал регион - используется только вручную выбранный регион. Автоматический выбор происходит по четырём способам в указанном порядке (используется первый успешно определённый вариант):

1. по IP (если разрешено и настроено в настройках модуля, и пользователь ещё не выбирал регион вручную)
2. по адресу (в зависимости от выбранного режима - по поддомену, домену или пути в URL,
3. по флагу базового региона (по умолчанию в нашей базе - Москва).
4. первый доступный регион в инфоблоке.

Например, при работе регионов на поддоменах, при первом заходе пользователя на krasnodar.test.ru регион определится как Краснодар, на khavarovsk.test.ru - Хабаровск. Но как только пользователь выберет свой регион вручную, например, Москва, при заходе даже на те же поддомены регион будет определяться как Москва.

Наш функционал, как и все подобные модули, использует макросы для вывода названий городов. Например, чтобы на какой-то странице, в статье, товаре, или любом другом месте вывести название города в формате "купить в Краснодаре", используйте макрос с названием города в предложном падеже: "купить в #WD_SEO_REGION_NAME_P#".

На текущий момент доступны следующие макросы (в скобках указан пример вывода в зависимости от региона):

• #WD_SEO_REGION_CODE# (krasnodar)
• #WD_SEO_REGION_NAME# (Краснодар)
• #WD_SEO_REGION_NAME_R# (Краснодара)
• #WD_SEO_REGION_NAME_D# (Краснодару)
• #WD_SEO_REGION_NAME_V# (Краснодар)
• #WD_SEO_REGION_NAME_T# (Краснодаром)
• #WD_SEO_REGION_NAME_P# (Краснодаре)

В целом, всё просто: за вывод кнопки выбора региона отвечает компонент webdebug.seo:regions.link, который можно использовать даже без параметров.

Поэтому, всё что необходимо сделать - добавить этот компонент в шапку сайта. Пример добавления кода:

<?$APPLICATION->IncludeComponent("webdebug.seo:regions.link", ".default", array());?>

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

Открываем файл /bitrix/templates/aspro_max/page_blocks/header/header_2.php.

Находим эту строку (на данный момент это строка №6):

$bIncludeRegionsList = $arRegions || ($arTheme['USE_REGIONALITY']['VALUE'] !== 'Y' && $arTheme['USE_REGIONALITY']['DEPENDENT_PARAMS']['REGIONALITY_IPCITY_IN_HEADER']['VALUE'] !== 'N');

Закомментируем её, добавив в начале символ решётки:

#$bIncludeRegionsList = $arRegions || ($arTheme['USE_REGIONALITY']['VALUE'] !== 'Y' && $arTheme['USE_REGIONALITY']['DEPENDENT_PARAMS']['REGIONALITY_IPCITY_IN_HEADER']['VALUE'] !== 'N');

Сразу после неё добавляем такую строку:

$bIncludeRegionsList = \Bitrix\Main\Loader::includeModule('webdebug.seo') && \WD\Seo\Regions\Manager::getInstance(SITE_ID)->isEnabled();

Это проверяет статус функционала регионов в нашем модуле - включён или выключен (галочка «Использовать регионы» в настройках модуля для данного сайта).

Далее, находим в этом же файле строку (на данный момент это строка №35):

<?\Aspro\Functions\CAsproMax::showRegionList();?>

Комментируем её, также добавляя перед кодом (но после символов <?) символ решётки:

<?#\Aspro\Functions\CAsproMax::showRegionList();?>

И сразу под ней размещаем компонент:

<?$APPLICATION->IncludeComponent("webdebug.seo:regions.link", ".default", array());?>

Также, конкретно в шаблоне aspro_max нужно добавить выбор региона в мобильной версии. Нужно открыть файл /bitrix/templates/aspro_max/page_blocks/header_mobile_menu_2.php (или с индексом 1, в зависимости от настроек aspro), закомментировать строку

CMax::ShowMobileRegions();

и после неё добавить строку

$APPLICATION->IncludeComponent("webdebug.seo:regions.link", ".default", array());

Всё! На этом добавление компонента закончено. Теперь, если в модуле для данного сайта включена галочка «Использовать регионы», то а данной области сайта будет показана ссылка, при нажатии на которую появится окно выбора региона.

Для работы данного компонента необходимо, чтобы на сайте был подключён jQuery. По умолчанию модуль сам подключает его (стандартным способом, из ядра Битрикс) версии 3, при необходимости в настройках модуля (раздел «Разное», опция «Версия jQuery, используемая на сайте» можно изменить версию или отменить автоматическое подключение.

Данная проблема может возникать на шаблоне Аспро Максимум при включённой опции «Всегда перенаправлять на выбранный регион».

Решение простое: следует добавить в исключения указанный файл:

/bitrix/templates/aspro_max/js/setTheme.php

Если в модуле для сайта заданы регионы, при открытии сайта в любом случае для пользователя должен определиться регион. Если пользователь сделал ручной выбор, то всегда будет действовать он, иначе проверяется регион по IP-адресу, если не определён - по поддомену/домену/адресу, если и это не привело к определению региона - используется базовый регион (если базового нет - используется первый найденный).

Данные из региона можно вывести различными способами. Один из наиболее удобных - использование макросов. По умолчанию доступны макросы, означающие ID, код и название региона, а также названия региона в разных падежах. Все они начинаются с префикса WD_SEO_REGION_ и обрамлены символами решётки:

• #WD_SEO_REGION_ID#

• #WD_SEO_REGION_CODE# (krasnodar)
  

• #WD_SEO_REGION_NAME# (Краснодар)
  

• #WD_SEO_REGION_NAME_R# (Краснодара)
  

• #WD_SEO_REGION_NAME_D# (Краснодару)

• #WD_SEO_REGION_NAME_V# (Краснодар)
  

• #WD_SEO_REGION_NAME_T# (Краснодаром)
  

• #WD_SEO_REGION_NAME_P# (Краснодаре)

Буква после NAME означает первую букву падежа в транслите (R - родительный, D - дательный, V - винительный, T - творительный, P - предложный).

В настройках модуля имеется возможность добавить алиасы (псевдонимы) для данных полей: это удобно если на сайте в текстах уже заданы макросы от других модулей, которые уже не используются.

Кроме того, модуль добавляет к описанным макросам дополнительные - из свойств инфоблока (по символьному коду). Например, если создать свойство с кодом PHONE (или phone) - тогда на сайте можно использовать макрос #WD_SEO_REGION_PHONE#.

Также, модуль предоставляет несколько API-методов для получения текущего региона. Методом get() можно получить текущие базовые данные региона:

print_r(\WD\Seo\Regions\Manager::getInstance(SITE_ID)->get());

Array
(
    [ID] => 123
    [CODE] => krasnodar
    [NAME] => Краснодар
    [NAME_2] => 
    [NAME_R] => Краснодара
    [NAME_D] => Краснодару
    [NAME_V] => Краснодар
    [NAME_T] => Краснодаром
    [NAME_P] => Краснодаре
    [IS_BASE] => N
)

print_r(\WD\Seo\Regions\Manager::getInstance(SITE_ID)->get());

print_r(\WD\Seo\Regions\Manager::getInstance(SITE_ID)->getRegionId());

Внимание! Здесь описан механизм добавления ссылок при генерации карты сайта средствами Битрикса. При генерации карты сайта средствами модуля всё выполняется автоматически, без необходимости что-то донастраивать.

Запуск процесса добавления ссылок происходит в момент окончания генерации Битриксом карты сайта, поддерживается как старый функционал генерации карты сайта (через модуль «Поиск» - файл sitemap_index.php), так и новый (через пункт меню «Маркетинг» - файл sitemap.xml). В зависимости от настройки модуля «Мгновенная модификация карты сайта» запуск генерации происходит либо непосредственно в момент окончания генерации Битриксом карты сайта, либо в этот момент создаётся агент, который в ближайшее время запустит этот процесс.

Во время выполнения операции модуль отбирает из всех имеющихся ссылок активные и разрешённые для выгрузки (галочка «Запретить добавление в карту сайту» в каждой ссылке), и выгружает их в файлы вида webdebug_seo_1.xml в корне сайта (и так - для каждого сайта).

После окончания генерации XML-файлов модуль в созданные Битриксом карты сайта дописывает ссылки на созданные модулем карты. Таким образом, в итоговой карте сайта имеется всё то, что выгрузил Битрикс и всё то, что выгрузил наш модуль.

Также, запуск генерации карты сайта можно выполнить через API:

\WD\Seo\UrlSitemap::execute('s1', 'sitemap.xml');

где первый аргумент - идентификатор сайта (обязателен), а второй - имя файла карты сайта, в который нужно вставить запись-указатель на карту сайта модуля (необязательный, если не указан - значение берётся из параметра «Имя файла карты сайта» в настройках модуля).

Начиная с версии 22.24.0 модуль умеет для шаблона aspro.max генерировать разные ссылки для разных поддоменом - этот функционал работает автоматически, запускается в момент окончания генерации карт для разных регионов.

Если в настройках модуля для конкретного сайта параметр «Отслеживание изменений в карте сайта» (в разделе «Настройки ссылок») указан верно, то проблема, скорее всего, заключается в незаполненности значения «Путь к корневой папке веб-сервера для этого сайта».

Проверьте настройки каждого сайта и для каждого сайта укажите собственный путь.

Генератор карты сайта модуля (добавлен в обновлении 23.5.0) немного похож на родной генератор карты сайта Битрикс (тот, который расположен в меню «Маркетинг» - «Поисковая оптимизация». Однако, в отличие от большинства остальных модулей, наш модуль не использует его в качестве основы.

Отличия от родного функционала следующие:

1. поддержка функционала «Регионы»: карта сайта генерирует разные адреса для разных режимов регионов, а также учитывает исключения (для режима «виртуальные разделы»), карта сайта может использоваться как с регионами, так и без них,
2. поддержка выгрузки изображений для статических папок/файлов, а также для инфоблоков - разделов и элементов (можно выбрать из каких свойств брать изображения для выгрузки),
3. поддержка выгрузки «красивых» ссылок модуля,
4. возможность запуска через Cron по расписанию (при этом доступна очень лёгкая настройка прямо из модуля), при этом возможность ручного запуска также имеется,
5. карта сайта хранится не в корне сайта (физически в корне сайта вообще нет никаких файлов карты сайта, и это нормально).

Особенно интересен здесь последний пункт. Обратите внимание, что в корне сайта файлы карты сайта не сохраняются. Более того, если нужно чтобы файл (обычно "sitemap.xml") работал через наш модуль, в корне сайта не должно быть этого файла! Иначе будет открываться именно этот файл, а не карта сайта из нашего модуля. А если этого файла нет, будет открываться карта сайта из нашего модуля.

Наверняка у Вас возник вопрос "как же это работает?". На самом деле, всё легко и просто. Если файла sitemap.xml в корне сайта нет, то при обращении к нему вся работа идёт через файл 404.php и правила обработки адресов (так работают все ЧПУ в Битриксе) - и примерно так же работает наш модуль. Т.е. всё, что требуется для корректной работы - чтобы не было файла с картой сайта в корне сайта, и чтобы на сайте корректно был настроен показ ошибки 404. Всё остальное модуль сделает сам: при обращении к sitemap.xml, если этого файла нет, модуль выводит содержимое соответствующего ему файла (с индексной картой сайта), который находится в отдельной папке, и эта индексная карта сайта содержит ссылки на вложенные карты сайта - на их реальный физические адреса в папке.

Благодаря этому, в корне сайта не хранится большое количество файлов карты сайта (они хранятся в отдельной папке, это настраивается), что значительно повышает удобство работы с файлами сайта.

Использование функционала очень простое: сначала укажите все основные параметры в форме настроек (вкладка «Настройки»), затем выберите какие обычные папки/файлы будут выгружены, и укажите (если требуется) картинки и названия картинок (вкладка «Файлы»), и затем настройте инфоблоки (вкладка «Инфоблоки») - выберите что выгружать (разделы и (или) элементы, картинки к ним), сохраните настройки и нажмите кнопку «Запустить генерацию карты сайта». Затем проверьте - всё ли в порядке (это можно сделать включив функционал и обратившись к файлу через браузер, либо через открыл файл вручную в указанной папке). Если всё в порядке - можно настроить автоматическую генерацию карты сайта, например, раз в сутки.

Генерация файла robots.txt (добавлена в обновлении 23.5.0), как и генерация карты сайта в модуле, работает нестандартно: это сделано для простоты и удобства настройки.

Чтобы функционал robots.txt нашего модуля работал, в корне сайта не должно быть файла robots.txt! Тогда модуль при обращении к этому файлу будет отдавать содержимое, которое генерирует сам.

В отличие от стандартного генератора robots.txt наш модуль имеет несколько преимуществ:

1. работает автоматически, т.е. перегенерировать никогда не требуется,
2. поддерживает функционал «Регионы», в частности, добавление карты сайта, соответствующей выбранному режиму регионов,
3. отсутствуют устаревшие (не поддерживаемые поисковиками) директивы: Host и Crawl-delay.

Процесс настройки очень простой - сначала нужно указать для каких роботов планируете вносить настройки (по умолчанию просто символ звёздочки, означающий всех роботов) - например, *, YandexBox, GoogleBot (каждая запись - на отдельный строке). Затем сохранить настройки, и в появившихся вкладках заполнить поля Disallow, Allow, Clean-param.

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

Необходимо в файл init.php добавить следующий обработчик:

addEventHandler('solverweb.sitemap', 'OnAfterXMLGenerate', function($arMap, $xmldata, $sitemap_filename, $base){
	if (\Bitrix\Main\Loader::includeModule('webdebug.seo') && $sitemap_filename) {
		\WD\Seo\UrlSitemap::execute($arMap['SITE_ID'], $sitemap_filename . '.xml');
	}
});

Также необходимо открыть файл /bitrix/modules/solverweb.sitemap/include.php и найти эту строку:

SWSitemapList::setEntityLastRun((int)$arMap['ID']);

Сразу после этой строки нужно вставить следующий код:

foreach (\GetModuleEvents(self::$MODULE_ID, "OnAfterXMLGenerate", true) as $arEvent){
	\ExecuteModuleEventEx($arEvent, array($arMap, $xmldata, self::$settings['sitemap_filename'], $base));
}

Теперь при окончании генерации карты сайта модулем solverweb.sitemap будет запускаться наш модуль, который допишет в сгенерированную карту ссылки модуля.

Обратите внимание, что карта сайта в указанном модуле должна генерироваться с отмеченной опцией «Разбить файл на части» (это важно!), а также в настройках нашего модуля необходимо указать корректное имя файла, если требуется (по умолчанию - sitemap.xml).

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

Событие получает массив фильтра, в котором по умолчанию только инфоблок и активность.

Вот пример реализации на сайте:

addEventHandler('webdebug.seo', 'onSitemapGetIBlockElementFilter', function(&$arFilter){
  if(in_array($arFilter['IBLOCK_ID'], [2, 3])){
    $arFilter['>CATALOG_PRICE_1'] = 2000;
   }
});

Этот обработчик нужно прописать (предварительно скорректировать) в init.php.

В данном примере для инфоблоков 2 и 3 мы запрещаем выгрузку товаров с ценой 2000р и ниже

addEventHandler('webdebug.seo', 'OnSitemapGetSteps', function(&$arSteps){
	$arSteps['MY_FILE'] = [
		'CALLBACK' => function(&$arSession, $exporter){
			$exporter->writeXml($arSession['FILES'], 'my_sitemap_file_custom.xml',
				file_get_contents($_SERVER['DOCUMENT_ROOT'].'/sitemap-test.xml'), NULL);
		},
	];
});

В административной части сайта перейдите в «SEO - мастер» - «Все ссылки», нажмите кнопку «Добавить ссылку», укажите все необходимые поля (кроме служебных) и сохраните.

Важный нюанс: если Вы заполните поле «Желаемый адрес», старая страница будет выполнять редирект на этот адрес.

В публичной части сайта задача выполняется ещё быстрее. Просто перейдите на нужную страницу, нажмите на панели управления кнопку «SEO - мастер», откроется окно с полями для заполнения, причём поле с текущим адресом уже будет заполнено. Поэтому Вы можете сразу перейти на вкладку «SEO-данные», заполнить требуемые значения и сохранить. Всё, готово!

В случае, если для какой-то страницы необходимо очистить сохранённые ранее данные, откройте эту страницу, нажмите кнопку «SEO - мастер», в открывшемся окне нажмите кнопку «Удалить данные по текущей странице» и подтвердите удаление.

Модуль «Универсальная галерея» использует особый вид макросов, который похож на макросы SEO-текстов нашего модуля, но имеет другой формат: ##G23#template_name#. Поэтому модуль, до версии 22.22.6, не имеет возможности работы с данным модулем.

Обновление 22.22.6 решает данную проблему, но при этом на сайте требуется прописать два дополнительных обработчика:

addEventHandler('webdebug.seo', 'OnBeforeSeoTextTransform', function($obSeoText, &$strText, &$arValues){
  if(\Bitrix\Main\Loader::includeModule('grain.gallery')){
    $strText = preg_replace('/##G([1-9][0-9]*)#([A-Za-z0-9\_\-\.]*)#/', '%grain_gallery_$1_$2%', $strText);
  }
});
addEventHandler('webdebug.seo', 'OnAfterSeoTextTransform', function($obSeoText, &$strText, $arValues){
  if(\Bitrix\Main\Loader::includeModule('grain.gallery')){
    $strText = preg_replace('/%grain_gallery_([1-9][0-9]*)_([A-Za-z0-9\_\-\.]*)%/', '##G$1#$2#', $strText);
  }
});

Их нужно прописать в файле init.php (обычно находится в папке /local/php_interface/ или в папке /bitrix/php_interface/), при этом прописывать через админку Битрикса нельзя (любая опечатка, ошибка, сбой проводит к тому, что весь сайт падает), нужно прописывать через FTP или SSH.

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

Опишем пример решения задачи, в которой требуется заменить, например, "rossiiskii-proizvoditel:net" на "inostrannogo-proizvodstva". Точно так же можно заменить, например, "newproduct:yes" на "novinki", "dostupno-v-rassrochku:da" на "rassrochka" и т.д.

Данная возможность доступна в модуле, начиная с версии 22.12.2 (точнее, возможность доступна и в более ранней версии, но не так удобно).

Пример кода обработчика:

addEventHandler('webdebug.seo', 'OnGenerateSeoUrlFilter', function(&$arFilterPath, $obGenerator, $arChainValues){
	foreach($arChainValues as $index => $arItem){
		if($arItem['PROPERTY']['CODE'] == 'IS_RUSSIAN'){
			switch($arItem['CONVERTED_DATA']['VALUE_CODE']){
				case 'Y':
					$arFilterPath[$index]['CUSTOM'] = 'rossiiskogo-proizvodstva';
					break;
				case 'N':
					$arFilterPath[$index]['CUSTOM'] = 'inostrannogo-proizvodstva';
					break;
			}
		}
	}
	unset($arItem);
});

Данная проблема решается обновлением 21.23.0. При этом, после установки обновления необходимо внести одно изменение в шаблоне.

Необходимо найти папку используемого шаблона компонента bitrix:catalog.smart.filter, открыть файл ajax.php и перед выводом результата (обычно через echo), например, echo $json; или echo CUtil::PHPToJSObject($arResult, true); добавить этот код:

if(\Bitrix\Main\Loader::includeModule('webdebug.seo')){
 \WD\Seo\SmartFilter\AutoSeo::set($arResult, $arParams);
 \WD\Seo\HttpResponse::changeJson($json); /* Только для aspro.max и aspro.lite */
}

В общем случае редактировать необходимо файл /bitrix/templates/aspro_next/components/bitrix/catalog/main/page_blocks/list_elements_1.php, он содержит код вывода списка товаров из раздела, включая описание раздела.

В коде имеется два блока - один отвечает за верхнее описание, второй - за нижнее. Место вывода описаний указывается в настройках аспро.

Блок кода, отвечающий за вывод описание сверху:

<?if($arParams["SHOW_SECTION_DESC"] != 'N' && strpos($_SERVER['REQUEST_URI'], 'PAGEN') === false):?>
	<?ob_start();?>
	<?if($posSectionDescr === "BOTH"):?>
		<?if ($arSection[$section_pos_top]):?>
			<div class="group_description_block top">
				<div><?=$arSection[$section_pos_top]?></div>
			</div>
		<?endif;?>
	<?elseif($posSectionDescr === "TOP"):?>
		<?if($arSection[$arParams["SECTION_PREVIEW_PROPERTY"]]):?>
			<div class="group_description_block top">
				<div><?=$arSection[$arParams["SECTION_PREVIEW_PROPERTY"]]?></div>
			</div>
		<?elseif($arSection["DESCRIPTION"]):?>
			<div class="group_description_block top">
				<div><?=$arSection["DESCRIPTION"]?></div>
			</div>
		<?elseif($arSection["UF_SECTION_DESCR"]):?>
			<div class="group_description_block top">
				<div><?=$arSection["UF_SECTION_DESCR"]?></div>
			</div>
		<?endif;?>
	<?endif;?>
	<?
	$html = ob_get_clean();
	$APPLICATION->AddViewContent('top_desc', $html);
	$APPLICATION->ShowViewContent('sotbit_seometa_top_desc');
	$APPLICATION->ShowViewContent('top_desc');
	?>
<?endif;?>

Блок, отвечающий за вывода описаний внизу:

<?if($arParams["SHOW_SECTION_DESC"] != 'N' && strpos($_SERVER['REQUEST_URI'], 'PAGEN') === false):?>
	<?ob_start();?>
	<?if($posSectionDescr === "BOTH"):?>
		<?if($arSection[$section_pos_bottom]):?>
			<div class="group_description_block bottom">
				<div><?=$arSection[$section_pos_bottom]?></div>
			</div>
		<?endif;?>
	<?elseif($posSectionDescr === "BOTTOM"):?>
		<?if($arSection[$arParams["SECTION_PREVIEW_PROPERTY"]]):?>
			<div class="group_description_block bottom">
				<div><?=$arSection[$arParams["SECTION_PREVIEW_PROPERTY"]]?></div>
			</div>
		<?elseif ($arSection["DESCRIPTION"]):?>
			<div class="group_description_block bottom">
				<div><?=$arSection["DESCRIPTION"]?></div>
			</div>
		<?elseif($arSection["UF_SECTION_DESCR"]):?>
			<div class="group_description_block bottom">
				<div><?=$arSection["UF_SECTION_DESCR"]?></div>
			</div>
		<?endif;?>
	<?endif;?>
	<?
	$html = ob_get_clean();
	$APPLICATION->AddViewContent('bottom_desc', $html);
	$APPLICATION->ShowViewContent('bottom_desc');
	$APPLICATION->ShowViewContent('sotbit_seometa_bottom_desc');
	$APPLICATION->ShowViewContent('sotbit_seometa_add_desc');
	?>
<?endif;?>

Сначала вверху файла добавляем php-код:

global $wdSeoUrlData;

Далее, общий принцип простой: в каждом из указанных блоков имеется две ветки условий:

<?if($posSectionDescr === "BOTH"):?>

<?elseif($posSectionDescr === "BOTTOM"):?>

<?if(isset($wdSeoUrlData['DESCRIPTION_TOP']) && strlen($wdSeoUrlData['DESCRIPTION_TOP'])):?>

<div class="group_description_block top">
	<div><?=$wdSeoUrlData['DESCRIPTION_TOP']?></div>
</div>

<?if(isset($wdSeoUrlData['DESCRIPTION_BOTTOM']) && strlen($wdSeoUrlData['DESCRIPTION_BOTTOM'])):?>

<div class="group_description_block bottom">
	<div><?=$wdSeoUrlData['DESCRIPTION_BOTTOM']?></div>
</div>

<?if($arParams["SHOW_SECTION_DESC"] != 'N' && strpos($_SERVER['REQUEST_URI'], 'PAGEN') === false):?>
	<?ob_start();?>
	<?if($posSectionDescr === "BOTH"):?>
		<?if(isset($wdSeoUrlData['DESCRIPTION_TOP']) && strlen($wdSeoUrlData['DESCRIPTION_TOP'])):?>
			<div class="group_description_block top">
				<div><?=$wdSeoUrlData['DESCRIPTION_TOP']?></div>
			</div>
		<?elseif ($arSection[$section_pos_top]):?>
			<div class="group_description_block top">
				<div><?=$arSection[$section_pos_top]?></div>
			</div>
		<?endif;?>
	<?elseif($posSectionDescr === "TOP"):?>
		<?if(isset($wdSeoUrlData['DESCRIPTION_TOP']) && strlen($wdSeoUrlData['DESCRIPTION_TOP'])):?>
			<div class="group_description_block top">
				<div><?=$wdSeoUrlData['DESCRIPTION_TOP']?></div>
			</div>
		<?elseif($arSection[$arParams["SECTION_PREVIEW_PROPERTY"]]):?>
			<div class="group_description_block top">
				<div><?=$arSection[$arParams["SECTION_PREVIEW_PROPERTY"]]?></div>
			</div>
		<?elseif($arSection["DESCRIPTION"]):?>
			<div class="group_description_block top">
				<div><?=$arSection["DESCRIPTION"]?></div>
			</div>
		<?elseif($arSection["UF_SECTION_DESCR"]):?>
			<div class="group_description_block top">
				<div><?=$arSection["UF_SECTION_DESCR"]?></div>
			</div>
		<?endif;?>
	<?endif;?>
	<?
	$html = ob_get_clean();
	$APPLICATION->AddViewContent('top_desc', $html);
	$APPLICATION->ShowViewContent('sotbit_seometa_top_desc');
	$APPLICATION->ShowViewContent('top_desc');
	?>
<?endif;?>

<?if($arParams["SHOW_SECTION_DESC"] != 'N' && strpos($_SERVER['REQUEST_URI'], 'PAGEN') === false):?>
	<?ob_start();?>
	<?if($posSectionDescr === "BOTH"):?>
		<?if(isset($wdSeoUrlData['DESCRIPTION_BOTTOM']) && strlen($wdSeoUrlData['DESCRIPTION_BOTTOM'])):?>
			<div class="group_description_block bottom">
				<div><?=$wdSeoUrlData['DESCRIPTION_BOTTOM']?></div>
			</div>
		<?elseif($arSection[$section_pos_bottom]):?>
			<div class="group_description_block bottom">
				<div><?=$arSection[$section_pos_bottom]?></div>
			</div>
		<?endif;?>
	<?elseif($posSectionDescr === "BOTTOM"):?>
		<?if(isset($wdSeoUrlData['DESCRIPTION_BOTTOM']) && strlen($wdSeoUrlData['DESCRIPTION_BOTTOM'])):?>
			<div class="group_description_block bottom">
				<div><?=$wdSeoUrlData['DESCRIPTION_BOTTOM']?></div>
			</div>
		<?elseif($arSection[$arParams["SECTION_PREVIEW_PROPERTY"]]):?>
			<div class="group_description_block bottom">
				<div><?=$arSection[$arParams["SECTION_PREVIEW_PROPERTY"]]?></div>
			</div>
		<?elseif ($arSection["DESCRIPTION"]):?>
			<div class="group_description_block bottom">
				<div><?=$arSection["DESCRIPTION"]?></div>
			</div>
		<?elseif($arSection["UF_SECTION_DESCR"]):?>
			<div class="group_description_block bottom">
				<div><?=$arSection["UF_SECTION_DESCR"]?></div>
			</div>
		<?endif;?>
	<?endif;?>
	<?
	$html = ob_get_clean();
	$APPLICATION->AddViewContent('bottom_desc', $html);
	$APPLICATION->ShowViewContent('bottom_desc');
	$APPLICATION->ShowViewContent('sotbit_seometa_bottom_desc');
	$APPLICATION->ShowViewContent('sotbit_seometa_add_desc');
	?>
<?endif;?>

В связи с ошибкой в шаблоне умного фильтра (версия 1.1.0) необходимо в result_modifier.php шаблона компонента умного фильтра добавить эту строку:

if(\Bitrix\Main\Loader::includeModule('webdebug.seo')){
  $arParams['FORM_URL'] = $arResult["JS_FILTER_PARAMS"]["SEF_SET_FILTER_URL"];
}

Аспро заменяет макросы регионов только там, где разработчики предусмотрели заранее, а при AJAX-фильтрации данные по регионам находятся отдельно, поэтому для AJAX-фильтрации это необходимо сделать самостоятельно. Необходимо в файле init.php на сайте добавить такой обработчик:

addEventHandler('webdebug.seo', 'onChangeFilterAjaxUrl', function(&$arJson, $strSiteId, $strUrl, $arSeoUrl){
	if(\Bitrix\Main\ModuleManager::isModuleInstalled('aspro.max')){
		\CMax::setRegionSeoMarks();
		$func = function(&$content){
			global $arRegion;
			foreach(\CMaxRegionality::$arSeoMarks as $mark => $field)
			{
				if(strpos($content, $mark) !== false)
				{
					if($arRegion)
					{
						if(is_array($arRegion[$field])){
							$value = $bCompSaleOrderAjaxPost ? trim(\Bitrix\Main\Web\Json::encode($arRegion[$field]['TEXT']), '"') : $arRegion[$field]['TEXT'];
							$content = str_replace(array($mark, str_replace('#REGION_TAG_', '#REGION_STRIP_TAG_', $mark)), array($value, strip_tags($value)), $content);
						}
						else{
							$value = $bCompSaleOrderAjaxPost ? trim(\Bitrix\Main\Web\Json::encode($arRegion[$field]), '"') : $arRegion[$field];
							$content = str_replace(array($mark, str_replace('#REGION_TAG_', '#REGION_STRIP_TAG_', $mark)), array($value, strip_tags($value)), $content);
						}
					}
					else{
						$content = str_replace(array($mark, str_replace('#REGION_TAG_', '#REGION_STRIP_TAG_', $mark)), '', $content);
					}
				}
			}
		};
		foreach(['TITLE', 'H1', 'KEYWORDS', 'DESCRIPTION'] as $key){
			if(isset($arJson['WD_SEO_META'][$key]) && mb_strlen($arJson['WD_SEO_META'][$key])){
				$func($arJson['WD_SEO_META'][$key]);
			}
		}
	}
});

Данная проблема является дополнительным побочным эффектом проблемы, связанной с ошибкой 404.

В данном шаблоне сайдбар выводится по такому условию:

<?if(!defined("ERROR_404")):?>
	<?$APPLICATION->IncludeComponent("bitrix:main.include", ".default", Array(
		"AREA_FILE_SHOW" => "sect",
			"AREA_FILE_SUFFIX" => "leftBlock",
			"AREA_FILE_RECURSIVE" => "Y",
			"EDIT_TEMPLATE" => "",
		),
		false
	);?>
<?endif;?>

А «красивые» адреса работают через страницу 404.php (как и многие другие в Битриксе), т.е. при срабатывании «красивого» адреса сначала подключается этот файл, затем определяется константа ERROR_404, и только потом подключается Битрикс. В итоге в шаблоне блок не будет никогда показываться.

Решение простое: всё, что следует выполнить, это в файле /404.php поменять указанные ниже строки, чтобы они были именно в таком порядке:

require($_SERVER["DOCUMENT_ROOT"]."/bitrix/header.php");
CHTTP::SetStatus("404 Not Found");
@define("ERROR_404", "Y");

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

Например, стандартно заголовок должен задаваться как $APPLICATION->setTitle() - и благодаря хитрым технологиям Битрикса заголовок подставляется в тег <h1> в конце генерации страницы. А если программист на сайте сделал простое <h1><?=$arResult["NAME"]?></h1> - модуль никогда не сможет менять этот заголовок. В таком случае помогут либо костыли, которые усложнят всё ещё больше, либо переделка к варианту, который и должен быть (т.е. использование $APPLICATION->showTitle(false))

Данная проблема связана с URL-адресами. Фактически модуль создаёт новую ссылку, которая должна работать только по заданному адресу. И она работает, пока адрес остаётся прежним.

На многих сайтах при сортировке в адресе появляются новые GET-параметры, например: ?sort=sort&order=desc, поэтому это уже не считается ссылкой модуля.

Другими словами, когда модуль видит ссылку /catalog/televizory-samsung/ он понимает, что это ссылка модуля, т.к. для данной ссылки имеется запись в таблице модуля. А когда модуль видит ссылку /catalog/televizory-samsung/?sort=sort&order=desc он не находит для неё соответствия и поэтому страница не работает.

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

После этого модуль будет определять страницу /catalog/televizory-samsung/?sort=sort&order=desc как страницу /catalog/televizory-samsung/ (т.е. отбрасывать эти ненужные параметры), и ссылка будет корректно работать.

Проблема связана с механизмом работы модуля (это также связано с механизмом обработки адресов и страницей /404.php). Начнём с небольшого примера.

Если Вы создаёте ЧПУ-ссылки, начинающиеся с /catalog/ - Битрикс обрабатывает эти ссылки правилами обработки, и, подключает php-файл, указанный в правилах обработки: в правилах для каталога обычно имеется правило #^/catalog/#, указывающее на файл /catalog/index.php, Битрикс подключает этот файл, в он подключает ядро Битрикса и страница отрабатывает как обычно.

Если же ссылка не начинается с /catalog/, Битрикс не находит правило обработки, подключает файл /404.php, который и устанавливает статус (если CHTTP::SetStatus вызывается до подключения header.php) и заголовок. Далее наш модуль отрабатывает корректно,  в т.ч. устанавливая код ответа 200, но константа, определяющая режим 404 уже установлена, и отменить её нет возможности.

Соответственно, если Вы столкнулись с подобной проблемой, необходимо в файл 404.php (в корне сайта) внести корректировку: установка статуса 404 и установка константы ERROR_404 должны быть после подключения файла /bitrix/header.php:

require($_SERVER["DOCUMENT_ROOT"]."/bitrix/header.php");
CHTTP::SetStatus("404 Not Found");
@define("ERROR_404","Y");

Если Вы настраиваете одно правило на генерацию ссылок по свойствам Бренд + Тип + Размер, модуль сгенерирует ссылки, которые соответствуют выбору именно трёх этих параметров. Если необходимо, чтобы модуль также создал ссылки для комбинации Бренд + Тип - или Тип + Размер - то для этого следует создать отдельные правила. Да, это увеличивает работ. Но это обеспечивает качество создаваемых SEO-данных. Дополнительная информация в вопросе Можно ли правило, настроенное для 1 раздела и 3 свойств, применить к другим разделам и правилам?.

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

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

Модуль определяет протокол (https или http) не из текущего адреса, что является ненадёжным, а из настроек.

Соответственно, достаточно зайти на страницу "Сайты" в нашем модуля, и для нужного сайта указать режим https:

Эта проблема может быть по нескольким причинам.

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

Другой возможный случай - проблема с конфигурацией сервера или сайта. Зафиксирован случай, когда штатный метод определения протокола HttpRequest::isHttps() сообщает, что текущий протокол - http даже когда протокол https. В данном случае необходимо разбираться, начиная с изучения данных в $_SERVER: ключи SERVER_PORT и HTTPS.

Модуль устанавливает канонические адреса штатным способом:

$APPLICATION->setPageProperty('canonical', 'https://site.ru/catalog/');

Поэтому в случае наличия каких-либо проблем с их установкой на сайте, проблему следует искать на самом сайте. Среди распространённых проблем:

1. тег canonical уже ранее был настроен, и теперь его работа пересекается с работой модуля,
2. средства определения канонических адресов модуля установлены в кешируемый файл шаблона - template.php или result._modifier.php, поэтому тег canonical в таких случаях будет корректно выводиться только при первом открытии страницы после сброса кеша.

Нам поступает большое количество пожеланий для развития модуля, но не все из них возможно реализовать в модуле. Например:

1. добавить возможность в правиле указать несколько разделов сразу. Такой возможности нет, т.к. правило - это сущность, которая по логике может быть прикреплена только к одному разделу, от этого зависит всё. В первую очередь, генерируемые адреса, но также и набор используемых значений свойств (например, в одном разделе используются одни бренды, в другом - другие, пусть даже похожие), соответственно конечный набор ссылок строится именно по использованных свойствам в выбранном разделе.

Данная проблема может возникать в случаях, когда компонент каталога (обычно bitrix:catalog) работает в AJAX-режиме, и в его настройках включена опция «Включить эмуляцию навигации браузера».

Данную проблему нельзя назвать проблемой в прямом смысле.

Это особенность работы региональности в различных модулях - такие региональные метки заменяются только при обычном открытии страниц, а при AJAX-запросах это не может быть заменено автомтически, поэтому, если Вы используете макросы регионов в заголовке (а также в заголовке окна браузера, описании и ключевых словах), необходимо программировать на сайте обработчик, используя событие модуля onChangeFilterAjaxUrl.

Ниже приведён пример для модуля aspro.max, где $func - это функция, которая использует код в таком виде, как он написан в aspro.max:

addEventHandler('webdebug.seo', 'onChangeFilterAjaxUrl', function(&$arJson, $strSiteId, $strUrl, $arSeoUrl){
	if(\Bitrix\Main\ModuleManager::isModuleInstalled('aspro.max')){
		\CMax::setRegionSeoMarks();
		$func = function(&$content){
			global $arRegion;
			foreach(\CMaxRegionality::$arSeoMarks as $mark => $field)
			{
				if(strpos($content, $mark) !== false)
				{
					if($arRegion)
					{
						if(is_array($arRegion[$field])){
							$value = $bCompSaleOrderAjaxPost ? trim(\Bitrix\Main\Web\Json::encode($arRegion[$field]['TEXT']), '"') : $arRegion[$field]['TEXT'];
							$content = str_replace(array($mark, str_replace('#REGION_TAG_', '#REGION_STRIP_TAG_', $mark)), array($value, strip_tags($value)), $content);
						}
						else{
							$value = $bCompSaleOrderAjaxPost ? trim(\Bitrix\Main\Web\Json::encode($arRegion[$field]), '"') : $arRegion[$field];
							$content = str_replace(array($mark, str_replace('#REGION_TAG_', '#REGION_STRIP_TAG_', $mark)), array($value, strip_tags($value)), $content);
						}
					}
					else{
						$content = str_replace(array($mark, str_replace('#REGION_TAG_', '#REGION_STRIP_TAG_', $mark)), '', $content);
					}
				}
			}
		};
		foreach(['TITLE', 'H1', 'KEYWORDS', 'DESCRIPTION'] as $key){
			if(isset($arJson['WD_SEO_META'][$key]) && mb_strlen($arJson['WD_SEO_META'][$key])){
				$func($arJson['WD_SEO_META'][$key]);
			}
		}
	}
});

Проблемы могут быть самого разного характера. Опишем некоторые из них.

Некоторые функции (или классы) подключаются без проверки на повторное подключение. В данном случае следует понимать принцип работы модуля: для «красивых» адресов (в т.ч. сгенерированных страниц SEO для умного фильтра) модуль при подмене адресов выполняет повторное подключение скриптов Битрикса. Т.к. они выполняются через require_once, то дважды они не выполняются. Однако иногда программисты прямо в шаблонах определяют свои функции: такой подход уже приводит к ошибке когда только один и тот же шаблон подключается два раза (если того требует логика работы сайта), т.е. это неправильно. При работе модуля такой код также выполнится дважды. И если какая-то функция где-то в шаблоне определена (хотя в шаблонах функции вообще лучше не определять, это плохо) без использования function_exists, то это потенциальная проблема.

Нужно сказать, что на данный момент мы сталкивались только с описанной выше проблемой. Но также сайт после установки модуля может упасть и по другим причинам - например, если на сайте используется слишком старая (или наоборот - слишком новая) версия PHP.

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

Другой частой проблемой является ошибка с кодировкой таблиц в базе - для этого можно запустить стандартный инструмент «Проверка сайта» в Битриксе, если проверке покажет ошибки, связанные с кодировками - вероятно, проблема в этом. Например, может так получиться, что кодировка таблицы сайтов Битрикса отличается от кодировки таблицы сайтов модуля, и тогда их совместная работа невозможна, будет ошибка "Mysql query error: (1267) Illegal mix of collations".

Возможны и другие причины. Если не получается понять причину самостоятельно - напишите нам, мы обязательно поможем.

Нас часто спрашивают: а почему модуль не может просто так взять и выводить на сайте то, что в нём настраивают? Например, настроили красивую ссылку, с большим SEO-описанием, почему модуль автоматически это не выводит на сайте? Ответ простой: а где конкретно выводить? Вы можете составить технический алгоритм, который позволит автоматике с максимальной надёжностью прописать описание на сайте? И при этом чтобы страница не начала тормозить? Нет, рамках критериев универсальности, надёжности и производительности это невозможно.

Модуль сам по себе никогда не может на сайте что-то выводить. Всегда требуется где-то что-то отредактировать, чтобы разрешить модулю выводить что-либо. Это относится как в SEO-текстам, так и к ссылкам перелинковки.

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

К тому же, такие попытки требовали бы больших ресурсов и просто были бы ненадёжны.

Поэтому, философия модуля подразумевает ручной вывод всей необходимой информации на сайте. Автоматически ничего не выводится кроме базовых SEO-данных (заголовок страницы, заголовок браузера, описание, ключевые слова, канонический адрес) - и это работает только потому, что в шаблоне уже вручную прописано где должны выводиться эти данные, а модуль всего лишь устанавливает их по собственных правилам.

Таким образом, чтобы на сайте выводились дополнительные SEO-тексты, нужно в соответствующих шаблонах добавить вывод этих описаний. Чтобы показывались кнопки перелинковки - нужно разместить в соответствующем месте шаблона компонент перелинковки.

Данная проблема может быть связана с проактивным фильтром модуля безопасности. В таком случае необходимо открыть его настройки (Настройки - Проактивная защита - Проактивный фильтр - Исключения) и добавить страницу модуля:

/bitrix/admin/wd_seo_wm_popup.php*

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

Для этого используйте метод \WD\Seo\UrlTable::getList.

В качестве примера можете скачать архив с php-файлом, который необходимо разместить где-либо на сайте для демонстрации - этот пример получает все ссылки из модуля (осторожно! если в модуле созданы тысячи ссылок, страница может подвиснуть!) и выводит их, группируя по разделам.

скачать файл

Для добавления собственных пунктов в меню в Битриксе используются свои механизмы - в частности, .wd_seo.menu.php и .wd_seo.menu_ext.php - где wd_seo это произвольный символьный код Вашего типа меню (он может быть задан в настройках модуля «Управление структурой», но это необязательно).

Чтобы вывести ссылки модуля в меню, прежде всего нужно в настройках компонента меню (bitrix:menu) отметить галочку «Подключать файлы с именами вида .тип_меню.menu_ext.php».

Затем загрузить в корень сайта файл .wd_seo.menu_ext.php, и всё, дополнительных действий в общем случае не требуется, ссылки должны выводиться в меню. Но они могут понадобиться в каждом отдельном случае - по таким вопросам необходимо будет обращаться к разработчикам сайта (возможно, на большую часть вопросов сможет ответить и мы, если шаблон меню разработан корректно и стандартно).

Если требуется ссылки добавить в карту сайта, необходимо дополнительное действие - в настройках главного модуля, в параметре «Тип меню для нулевого уровня карты сайта» (секция «Карта сайта») добавить в конце строки wd_seo (через запятую), чтобы получилось примерно так:

При этом, может возникнуть ситуация, когда в карте сайта уже имеется какой-либо раздел каталога (напр., «Каталог» - «Одежда»), и от модуля выводится «Одежда» отдельным пунктом со вложенными пунктами. В таком случае, чтобы ссылки модуля выводились в первом пункте, нужно добавить в шаблоне компонента bitrix:main.map файл result_modifier.php, в котором запрограммировано слияние ссылок.