Как найти потери трафика после миграции сайта на Joomla

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

1. Сначала подтвердите, что просел именно поиск

Я не начинаю с переписывания .htaccess. Перед сложным переносом полезен технический аудит сайта: он фиксирует исходные URL и состояние инфраструктуры до изменений. Сначала сравниваю в Search Console клики и показы по датам: до переноса и после него. Падение кликов при стабильных показах может быть связано со сниппетами или спросом; падение показов по группе URL больше похоже на проблемы обхода, индексации либо соответствия старых и новых адресов. Это ещё не диагноз, а способ выбрать направление проверки. Сравнивайте одинаковые дни недели и не смешивайте органику с прямыми заходами и рекламой.

Для условной студии «Алтын-Логистик» я бы начал с таблицы: старый адрес, новый адрес, код ответа, конечный URL, наличие в sitemap и ссылка из раздела сайта. Если нет выгрузки до переноса, используйте сохранённую старую карту, прежнюю sitemap и данные Search Console; отчёт не обязан содержать каждый URL, который когда-либо был на сайте. Список страниц из текущей карты сам по себе не показывает, что именно исчезло. Сопоставление двух состояний показывает это гораздо надёжнее.

Не превращайте график в приговор CMS. После смены URL Google может переобходить и переиндексировать страницы, поэтому колебания видимости сами по себе не доказывают поломку. Но если старые адреса отдают 404, а новые не обнаруживаются, это уже проверяемая техническая проблема. Запишите дату переноса, какие разделы менялись и когда включили перенаправления. Эти простые отметки избавляют от споров о том, «когда всё началось».

• Сравнить клики и показы отдельно
• Сопоставить одинаковые периоды
• Зафиксировать дату и объём миграции

2. Проверьте старые адреса и ответы HTTP

Сканирование по ссылкам полезно, но wget --spider --recursive не является полной инвентаризацией сайта. Wget обходит найденные ссылки, а страницы без входящих ссылок, закрытые от обхода или присутствовавшие только в старой sitemap могут не попасть в результат. К тому же --spider проверяет доступность, а не понимает, что новая страница действительно заменяет старую. Поэтому запускайте его по ограниченному тестовому набору и сверяйте результат с сохранённой картой URL.

Пример осторожной проверки одного адреса:

curl -sS -o /dev/null -D - https://example.com/old-page

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

curl -sS -L -o /dev/null -w 'final=%{url_effective} status=%{http_code} redirects=%{num_redirects}\n' https://example.com/old-page

Вторая команда помогает увидеть итоговый код и количество переходов; для расследования отдельно сохраните заголовки, если нужно понять каждый шаг цепочки. Не делайте вывод только по первой строке curl -I -L: HEAD-запрос может обрабатываться сервером иначе, чем обычный GET.

Для каждого важного старого URL проверьте, что адрес либо ведёт постоянным серверным редиректом на содержательно подходящую страницу, либо возвращает настоящий 404/410, если замены нет. Перенаправлять весь архив на главную — плохая универсальная заглушка: Google предупреждает, что нерелевантные перенаправления могут восприниматься как soft 404. Если старая статья объединена с новой, перенаправление на объединённую страницу логично; если товара или материала больше нет, выдумывать замену не нужно.

Вместо порогов «исправлять после 200 ошибок» я сортирую список по важности: страницы с внешними ссылками и трафиком, посадочные, разделы и затем хвост. Ошибку, на которую никто не ссылается и которой нет в sitemap, не всегда надо чинить редиректом. В Search Console Google отдельно советует в первую очередь исправлять 404, на которые ссылается сам сайт или которые включены в sitemap. Это экономит время и не создаёт десятки бессмысленных перенаправлений.

• Проверить адреса из старой карты
• Сверить первый ответ и конечный URL
• Отделить настоящие замены от удалённых страниц

3. Настройте редиректы и Joomla SEF без догадок

Для постоянного переезда страницы Google рекомендует серверные постоянные перенаправления, например 301 или 308, если сервер позволяет их настроить. В Apache пример правила для адреса в корне может выглядеть так:

RewriteRule ^old-page$ /new-page [R=301,L]

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

Частая ошибка — искать в Joomla одну волшебную позицию для всех редиректов. Правило должно сработать до того, как запрос будет перехвачен несовместимым правилом, но точный порядок зависит от содержимого файла и сервера. Joomla в документации просит активировать SEF по шагам: переименовать htaccess.txt в .htaccess, проверить RewriteBase и включить URL rewriting через настройки. RewriteBase / подходит для корня, а при установке в подкаталог базовый путь должен учитывать эту папку. Не исправляйте $live_site наугад: проверка этой переменной не заменяет проверку фактического базового пути и ответа.

Есть ещё одна причина «правило записано, но ничего не происходит»: Apache должен разрешать нужные переопределения для .htaccess, а модуль mod_rewrite должен быть доступен. Для директив переписывания Apache указывает класс FileInfo; конкретные права задаются в конфигурации виртуального хоста. Если нет доступа к конфигу сервера, попросите хостера подтвердить AllowOverride и модуль, вместо того чтобы плодить одинаковые RewriteEngine On. Наличие этой строки само по себе не доказывает, что сервер применил правило.

Я не обещаю, что единственный редирект «вернёт PageRank» или что любая цепочка немедленно уничтожит позиции. Google советует избегать цепочек: они добавляют задержку и усложняют обработку; в рекомендациях для Googlebot указано держать их короткими, по возможности вести сразу к конечному адресу. Проверьте, нет ли круговой петли, перехода http→https→http, смены www и повторного добавления слеша. После правки прогоните старые адреса вместе с конечными URL, а не только главную.

• Проверить mod_rewrite и разрешения `.htaccess`
• Сверить RewriteBase с фактической папкой
• Сократить цепочки и убрать циклы

4. Сравните старую и новую карту сайта

Возьмите старый список URL и сравните с новыми адресами. Источником старых путей может быть прежняя sitemap, экспорт из Search Console, резервная копия, журналы веб-сервера и внутренняя карта разделов. Если миграция затронула навигацию с фильтрами, отдельно проверьте фасетную навигацию сайта. Источники дополняют друг друга: sitemap не обязана включать все адреса, которые были доступны пользователям, а логи видят только запросы, которые действительно пришли. Текущую sitemap выгрузите отдельно и проверьте, что в ней перечислены канонические новые URL, а не старые адреса, редиректы или служебные страницы.

В таблице оставьте по строке на старый URL и добавьте столбцы «новый URL», «код», «релевантная замена», «внутренние ссылки», «в sitemap». Так видно три разных ситуации: страница переехала и получила подходящий адрес; несколько материалов объединены; материал удалён без замены. Для первого и второго случая нужна аккуратная карта перенаправлений, для третьего обычно нужен честный статус удаления. Механически перенаправить каждый неизвестный путь на раздел сайта — способ скрыть проблему от таблицы, но не решить её для посетителя.

Для Joomla проверьте не только страницы, но и то, как настроены SEF и суффиксы URL. После включения URL rewriting может измениться вид адреса с index.php или без него; это не повод массово добавлять правило на весь сайт, пока не проверены конкретные пары старого и нового маршрута. Если сайт установлен в подкаталог, RewriteBase также может отличаться от /. Изменение одного параметра не чинит неверный маршрут в компоненте, отсутствующую страницу или неправильный canonical.

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

• Собрать старые URL из нескольких источников
• Сопоставить каждый адрес с назначением
• Обновить ссылки и новую sitemap

5. Проверьте индексацию, canonical и robots

В актуальной Search Console ищите отчёт «Индексирование страниц» и проверяйте отдельные адреса через проверку URL. Название «Покрытие», которое встречается в старых инструкциях, больше не подходит как ориентир по интерфейсу. Отчёт помогает увидеть группы проблем, но он не мгновенный и не охватывает каждую страницу. Для конкретного URL сначала проверьте результат live-теста, затем доступность для обхода, директиву noindex, canonical и ответ сервера. Запрос site:example.com не заменяет эти инструменты: выдача по оператору не является полным списком URL и не объясняет причину исключения.

На новых страницах проверьте rel="canonical": он должен указывать на текущий предпочтительный адрес, а не на старую страницу, тестовый домен или вариант с другим протоколом. Проверьте и robots.txt, и метатег noindex, и HTTP-заголовки, если сервер задаёт их отдельно. Если новый сайт случайно закрыт от обхода или несёт старую директиву, правильный 301 сам по себе не восстановит доступность целевой страницы. Сначала устраните блокировку, затем запросите повторную проверку важных URL.

Отправьте новую sitemap через отчёт Sitemap в Search Console и проверьте, что она доступна, корректна и содержит адреса нового сайта. При переносе Google предлагает сохранить старую и новую карты на период мониторинга: старые адреса будут постепенно исчезать из индексированных, а новые появляться. В предупреждениях для sitemap со старыми URL могут отображаться перенаправления — это ожидаемо во время переезда. Не удаляйте старые данные до того, как убедились, что карта соответствий полная и новые адреса открываются.

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

• Открыть отчёт «Индексирование страниц»
• Проверить canonical, robots и noindex
• Отправить новую sitemap и следить за логами

6. Отделите техническую ошибку от поведения и спроса

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

Проверьте шаблонные изменения после переноса: заголовок страницы, метаописание, основной H1, текст, изображения, структурированные данные и канонический адрес. Бывает, что адрес отвечает 200, но отдаёт пустой шаблон, страницу выбора языка или сообщение об ошибке. В таком случае серверный код выглядит «зелёным», а содержимое не решает задачу пользователя. Техническая проверка должна включать и открытие страницы в браузере, и просмотр HTML для важных шаблонов.

Не запускайте A/B-тестирование сразу после миграции, пока не стабилизированы адреса и аналитика. Иначе одновременно меняются URL, контент и интерфейс, а затем никто не понимает, что повлияло на результат. Сначала восстановите корректные перенаправления, внутренние ссылки и измерение трафика. Если просели только отдельные категории, разбирайте их отдельно: глобальная правка для локальной проблемы часто добавляет новые ошибки.

Для условной «Алтын-Логистик» итог аудита должен быть не фразой «Joomla просела», а списком проверяемых находок: какие прежние адреса потеряны, какие правила исправлены, где мешал SEF, что включено в sitemap и какие URL требуют повторной проверки. Я фиксирую для каждой находки исходный ответ, целевой URL, выполненное изменение и контрольный результат. Тогда владелец сайта видит, что именно сделано, а следующий специалист не начинает расследование с нуля.

• Сопоставить потери по группам страниц
• Проверить содержимое и шаблоны
• Зафиксировать изменения и контрольные URL

Частые вопросы