Продвижение сайта на Drupal в Москве

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

Модули и роутинг: базовый SEO-стек Drupal

Drupal — не «коробочная CMS со встроенным SEO», а конструктор, в котором почти всё решается архитектурой и набором модулей. Базовый стек — Pathauto (человекопонятные адреса по шаблонам), Metatag (управление title, description и Open Graph), Simple XML Sitemap и Redirect (301-редиректы и контроль дублей). Сам по себе Drupal эти задачи не закрывает: пока модули не установлены и не настроены под структуру спроса, адреса и метатеги формируются как придётся.

Ключевая особенность роутинга — у каждого материала есть системный путь /node/ID и псевдоним (ЧПУ), сгенерированный Pathauto. Оба адреса отвечают кодом 200, если не задать canonical и не закрыть системные пути. То же самое происходит при смене шаблона алиасов: старый псевдоним остаётся живым, новый добавляется — и один материал начинает отвечать по трём-четырём адресам. Мы фиксируем шаблоны Pathauto на старте, включаем автосоздание 301-редиректа при изменении алиаса и сверяем список путей с картой сайта.

Отдельный слой — служебные разделы. Drupal из коробки отдаёт /user/, /admin/, формы поиска и пути вида /node/ID/edit. Их закрываем и в robots.txt, и заголовком X-Robots-Tag, а не только метатегом: часть таких путей робот встречает по внутренним ссылкам ещё до того, как доберётся до HTML. Проверку этих настроек делаем в рамках технического аудита.

• Шаблоны Pathauto задаём отдельно для страниц, новостей, разделов и терминов таксономии — единый шаблон на всё даёт мусорные и слишком длинные адреса.
• Модуль Redirect держим включённым с автосозданием редиректа при смене алиаса: это страховка от потери адресов при работе редакторов.
• Simple XML Sitemap настраиваем так, чтобы в карту попадали только индексируемые материалы, а не все ноды подряд.

Права доступа и модерация: часть сайта робот просто не видит

Это то, чего у других CMS почти нет в таком объёме. В Drupal права описываются ролями и разрешениями вплоть до отдельного материала: один раздел открыт всем, другой — только сотрудникам, третий — партнёрам после авторизации. Для анонимного посетителя (а поисковый робот — именно анонимный посетитель) закрытый материал отдаёт 403 или 404. Внутри сайта такие страницы прекрасно видны редактору и легко попадают в меню, перелинковку и карту сайта — а в индексе их нет и быть не может.

Второй источник той же проблемы — рабочие процессы модуля Content Moderation. Материал может быть в состоянии «черновик» или «на проверке» при живой опубликованной ревизии: редактор правит текст, видит свою версию и считает, что изменения уже на сайте. Робот в это время видит старую ревизию. Поэтому любые проверки индексации мы делаем от анонимного пользователя — в приватном окне и через инструменты Вебмастера и Search Console, а не глазами администратора.

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

• Проверяем сайт от анонимной роли: что доступно, что отдаёт 403, что при этом стоит в меню и хлебных крошках.
• Страницы за авторизацией не должны попадать в sitemap.xml и собирать внутренние ссылки со всех разделов — это слив краулингового бюджета.
• Публикация в Drupal — отдельное действие: черновик с правками не считается опубликованной страницей, даже если редактор видит новый текст.

Мультиязычность: языковые версии, префиксы и hreflang

Многоязычность — одна из причин, по которой Drupal берут в корпоративный и государственный сектор: перевод контента, интерфейса и настроек описан в ядре модулями Language, Content Translation, Interface Translation и Configuration Translation. Для SEO принципиален способ определения языка. Работающий вариант — префикс в адресе (/en/, /kk/): у каждой языковой версии свой постоянный URL, который робот может обойти и проиндексировать.

Что ломает индексацию — автоматический редирект по языку браузера или по стране IP. Робот приходит с одним набором заголовков и всегда попадает на одну версию, остальные для него недоступны. Такое определение языка мы отключаем или заменяем на ненавязчивую подсказку «доступна версия на другом языке», а связи между версиями описываем атрибутами hreflang, включая x-default. Как это устроено по шагам — в разборе про языковые версии и hreflang.

Третья ловушка — частичный перевод. Если материал переведён не полностью, Drupal по правилам языкового фолбэка показывает исходный текст на адресе другой языковой версии, и две страницы становятся текстовыми копиями. Решение здесь редакционное, а не техническое: либо переводим раздел целиком, либо не публикуем языковую версию раздела вовсе. Наполовину переведённая ветка — прямой кандидат в дубли и в малоценные страницы.

• Язык определяем префиксом в URL, а не редиректом по браузеру или стране — иначе часть версий роботу недоступна.
• hreflang прописываем взаимно, во все стороны, обязательно с x-default для стартовой версии.
• Не переведённые до конца разделы не публикуем: языковая копия исходного текста — это дубль, а не локализация.

Views и таксономия: откуда берётся лишний индекс

Списки на Drupal строятся модулем Views — каталог, новости, реестры документов, подборки по тегам. У любого такого списка есть сортировки, открытые фильтры и постраничная навигация, и все они живут в GET-параметрах: ?page=1, ?order=, ?field_..._value=. Комбинации перемножаются, и один список превращается в сотни адресов с почти одинаковым содержимым. Отдельно ловим ?page=0 — дубль первой страницы, который Views отдаёт при возврате назад по пагинации.

Второй источник — таксономия. Один материал может входить в несколько словарей и терминов сразу, а у каждого термина есть своя страница-список. В итоге и материал доступен из разных веток, и сами страницы терминов конкурируют между собой и с разделами каталога. Разбираем это через семантику: термины, под которые есть реальный спрос, становятся посадочными с собственным title, H1 и текстом; остальные закрываем noindex, follow — ссылочный вес по ним ходит, а в индексе они не мешают.

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

• Открытые фильтры Views и сортировки закрываем от обхода, а canonical списков ведём на адрес без параметров.
• ?page=0 приводим редиректом к адресу без параметра — иначе первая страница списка существует дважды.
• Страницы терминов делим на посадочные под спрос и служебные; служебные — noindex, follow.

Скорость и масштабирование под Core Web Vitals

Drupal гибкий, но тяжёлый: без кэширования крупный сайт отвечает медленно, и это видно уже по времени ответа сервера. Включаем внутреннее кэширование страниц для анонимных посетителей, динамический кэш для авторизованных, BigPipe для поэтапной отдачи блоков, агрегацию CSS и JS. Дальше картинки: стили изображений и адаптивные картинки в Drupal настраиваются штатно, к ним добавляем современные форматы и ленивую загрузку. Цель — держать Core Web Vitals в зелёной зоне; общий подход разбирали в материале про скорость загрузки.

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

Масштаб — сильная сторона платформы. Разветвлённая таксономия, несколько языков, тысячи материалов: Drupal тянет это без потери управляемости, если структура выстроена под кластеры спроса, а карта сайта разбита на части через индекс sitemap. Крупному сайту это заметно ускоряет переобход.

Переход на новую мажорную версию без потери позиций

Обновление Drupal между мажорными версиями — не установка апдейта, а фактически пересборка проекта: меняются API, часть сторонних модулей не имеет версии под новое ядро, тема переписывается. Для SEO это опаснее редизайна, потому что вместе с темой уезжают шаблоны метатегов, разметка и структура заголовков, а вместе с модулями — правила формирования адресов.

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

Отдельно проверяем шаблоны Pathauto: массовая перегенерация псевдонимов на большом сайте — самый быстрый способ обнулить накопленную историю адресов. Если шаблоны всё же меняются, старые псевдонимы сохраняем как редиректы, а не удаляем.

Корпоративный портал: факты о компании, авторство и нейроответы

Сайты, которые собирают на Drupal, обычно относятся к тематикам с повышенными требованиями к достоверности: медицина, финансы, образование, госсектор. Здесь ранжирование опирается не только на тексты, но и на подтверждаемость фактов — то, что описывают через E-E-A-T, а в YMYL-тематиках проверяют особенно строго. Поэтому на портале в явном виде нужны реквизиты, лицензии и разрешения, страницы руководителей и специалистов с квалификацией, даты публикации и обновления материалов.

Те же факты определяют, что о вас скажет нейросеть. Модель собирает ответ из того, что нашла и смогла разобрать: если структура организации, направления работы и контакты разложены по разметке Schema и не противоречат друг другу на разных языковых версиях, шанс попасть в ответ выше. Частые вопросы дополнительно размечаем через FAQ-разметку и следим, чтобы страница отвечала на вопрос в первом же абзаце, а не после трёх экранов подводки. Как это устроено целиком — в услуге AEO.

Последнее решается организационно: на портале с большой редакцией метатеги расходятся за месяцы. Мы задаём шаблоны Metatag по типам материалов и короткий регламент для редакции — какие поля обязательны, что писать в title и description, как оформлять заголовки. Без этого новые страницы постепенно съезжают в одинаковые метатеги, и техническими настройками это не удержать.

• Страницы о компании, лицензиях и специалистах — не «имиджевый» раздел, а источник фактов для поиска и для нейросетей.
• Дата публикации и дата обновления должны быть и в разметке, и на виду у читателя: для экспертных тематик это часть доверия.
• Регламент метатегов для редакторов обходится дешевле, чем регулярная чистка одинаковых title на тысячах материалов.

Для выездных услуг и филиалов уточняем фактическую зону работы: ЦАО, Хамовники, Пресненский район (Москва-Сити), Замоскворечье, Тверской район. Проверяем адреса, график, стоимость выезда и способы связи. Различия в локальной выдаче оцениваем по замерам; наличие района в списке не означает, что под него нужна отдельная посадочная.