Архитектура внутренней перелинковки при миграции с Drupal на headless CMS: опыт XSL в ОАЭ

Почему внутренняя перелинковка — критически важный этап миграции

Миграция с монолитной CMS вроде Drupal на headless-архитектуру — это не просто смена технологического стека. Это фундаментальное изменение в том, как контент хранится, обрабатывается и доставляется пользователям. В XSL мы столкнулись с этим вызовом при работе с клиентами из ОАЭ и Европы, и ключевым уроком стало: без грамотной архитектуры внутренней перелинковки вы рискуете потерять до 40% органического трафика.

Drupal из коробки предлагает мощную систему внутренних ссылок, где связи между страницами, таксономиями и медиафайлами управляются на уровне базы данных. В headless CMS эти связи нужно проектировать с нуля, учитывая особенности фронтенд-фреймворка (Next.js, Nuxt, Gatsby) и API-архитектуры. В этой статье я поделюсь подходом, который мы отточили на проектах для крупных e-commerce и медиаплощадок в Дубае.

Основные вызовы при миграции перелинковки

1. Потеря контекста связей между сущностями

В Drupal отношения между нодами, терминами таксономии и медиа определяются через entity reference. В headless CMS эти связи нужно либо:

• Хранить в виде ссылок в теле контента (например, в формате Markdown или HTML);
• Выносить в отдельные поля ссылок (например, массив UUID связанных записей);
• Использовать GraphQL-связи между типами контента.

Каждый подход имеет свои плюсы и минусы. Например, хранение ссылок в теле контента упрощает редактирование, но усложняет динамическую генерацию меню и «похожих статей».

2. Изменение URL-структуры

Drupal часто использует ЧПУ вида /blog/[node-id]/[alias]. В headless-архитектуре URL могут стать более плоскими (/blog/[slug]) или, наоборот, глубокими (/en/blog/category/[slug]). Это требует:

• Создания карты редиректов (301/302);
• Обновления всех внутренних ссылок в контенте;
• Настройки canonical-тегов для предотвращения дублирования.

3. Динамический рендеринг vs статическая генерация

Если в Drupal страницы генерируются на сервере, то в headless-архитектуре возможны разные подходы:

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

Архитектура перелинковки: пошаговый подход

Шаг 1: Аудит существующей структуры

Перед миграцией мы проводим глубокий анализ текущей перелинковки с помощью инструментов:

• Screaming Frog — для выгрузки всех внутренних ссылок и их анкоров;
• Google Search Console — для анализа страниц с высоким трафиком;
• Кастомные скрипты на PHP — для извлечения связей из Drupal API.

Результатом становится карта связей в формате CSV, где для каждой страницы указаны:

• Входящие ссылки (backlinks);
• Исходящие ссылки (outlinks);
• Тип связи (таксономия, автор, связанный контент).

Шаг 2: Выбор модели хранения связей

Мы тестировали три подхода на реальных проектах:

1. Связи в теле контента (Rich Text)

   Плюсы: простота редактирования, совместимость с любыми CMS (Strapi, Contentful, Sanity).

   Минусы: сложно обновлять ссылки при изменении URL, нет контроля над анкорами.

2. Отдельные поля ссылок (Reference Fields)

   Пример для Strapi:

   <content-type>
     <field name="related_articles" type="relation" target="api::article.article" />
   </content-type>

   Плюсы: гибкость, возможность программного управления связями.

   Минусы: требует кастомной логики на фронтенде для рендеринга.

3. Гибридный подход

   Основные связи хранятся в reference-полях, а дополнительные — в теле контента. Это наш рекомендуемый вариант для большинства проектов.

Шаг 3: Настройка API для фронтенда

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

• Для страницы статьи (Next.js + GraphQL):

  query GetArticle($slug: String!) {
    article(slug: $slug) {
      title
      content
      related_articles {
        slug
        title
        excerpt
      }
      categories {
        name
        slug
      }
    }
  }

• Для динамического меню (REST API):

  GET /api/menu?type=main
  Response:
  {
    "items": [
      {
        "title": "Blog",
        "url": "/blog",
        "children": [
          {
            "title": "SEO Tips",
            "url": "/blog/seo-tips",
            "related_count": 12
          }
        ]
      }
    ]
  }

Шаг 4: Реализация редиректов и обновление ссылок

Мы используем следующий алгоритм:

1. Создаем карту редиректов в формате source → target (например, /node/123 → /blog/new-slug).
2. Настраиваем серверные редиректы (Nginx/Apache) или middleware (Next.js).
3. Обновляем внутренние ссылки в контенте с помощью скриптов. Пример на Python:

import re
from bs4 import BeautifulSoup

def update_links(html, redirect_map):
    soup = BeautifulSoup(html, 'html.parser')
    for link in soup.find_all('a', href=True):
        if link['href'] in redirect_map:
            link['href'] = redirect_map[link['href']]
    return str(soup)

# Применяем ко всем статьям в CMS

Шаг 5: Тестирование и мониторинг

После миграции мы проводим:

• Автоматизированное тестирование с помощью Playwright или Cypress для проверки всех внутренних ссылок.
• Мониторинг 404 ошибок в Google Search Console и Sentry.
• Анализ поведения пользователей в Google Analytics (время на странице, глубина просмотра).

На одном из проектов для клиента из Абу-Даби мы обнаружили, что 15% внутренних ссылок вели на несуществующие страницы из-за ошибки в скрипте миграции. Благодаря мониторингу мы исправили это в течение 24 часов.

Инструменты, которые мы используем в XSL

Типичные ошибки и как их избежать

1. Игнорирование относительных ссылок

В Drupal часто используются относительные ссылки вида /node/123. При миграции их нужно либо:

• Заменить на абсолютные (https://example.com/blog/new-slug);
• Настроить базовый URL на фронтенде.

2. Потеря анкоров при миграции

Анкоры ссылок (<a href="/blog">Читать блог</a>) важны для SEO. Мы используем скрипты, которые сохраняют анкоры при обновлении URL.

3. Неучет мультиязычности

Если сайт поддерживает несколько языков, ссылки должны вести на соответствующую языковую версию. Например:

// Неправильно
<a href="/blog">Blog</a>

// Правильно
<a href="/en/blog" hreflang="en">Blog</a>

4. Забытые редиректы для медиафайлов

Изображения и PDF-файлы тоже имеют внутренние ссылки. Их URL нужно обновлять или настраивать редиректы.

Кейс: Миграция медиапортала в Дубае

Один из наших клиентов — крупный медиапортал в ОАЭ — столкнулся с проблемой: после миграции с Drupal на Strapi + Next.js трафик из поисковых систем упал на 30%. Анализ показал, что:

• 40% внутренних ссылок вели на несуществующие страницы;
• Структура URL изменилась с /ar/node/123 на /ar/news/[slug] без редиректов;
• Связи между статьями хранились в теле контента и не обновлялись при изменении URL.

Наше решение:

1. Создали карту редиректов для всех языковых версий (арабский, английский).
2. Перенесли связи между статьями в отдельные reference-поля в Strapi.
3. Настроили ISR в Next.js для обновления ссылок каждые 5 минут.
4. Добавили middleware для обработки 404 и показа похожих статей.

Результат: через 3 месяца трафик восстановился на 95%, а глубина просмотра выросла на 22%.

Выводы: как сделать миграцию безболезненной

1. Начинайте с аудита. Без понимания текущей структуры перелинковки миграция обречена на провал.
2. Выбирайте гибридную модель хранения связей. Reference-поля для критически важных связей, Rich Text — для гибкости.
3. Автоматизируйте обновление ссылок. Ручная работа здесь неэффективна и чревата ошибками.
4. Тестируйте на реальных пользователях. Запускайте A/B-тесты для проверки влияния изменений на поведение.
5. Мониторьте после миграции. Даже идеально спланированный процесс может дать сбой.

Миграция на headless CMS — это не просто технический апгрейд, а возможность переосмыслить архитектуру контента. В XSL мы рассматриваем этот процесс как шанс улучшить не только производительность, но и пользовательский опыт. Правильно спроектированная перелинковка — это фундамент, на котором строится вся дальнейшая работа.

Если у вас есть вопросы по миграции или вы планируете подобный проект — пишите мне в LinkedIn или на почту. Мы в XSL всегда готовы помочь бизнесу в ОАЭ и за его пределами.