AI-SEO аудит и подготовка перехода на PHP 8.3 для сайта на MODX Evolution
Технический аудит · MODX Evolution · PHP · AI-поиск
Аудит сайта мастерской памятников на MODX Evolution: исправление технического SEO, подготовка структурированных данных и проверка перехода на PHP 8.3. Работа велась на копии сайта, а обновление CMS проверялось на отдельном стенде.
Задача и условия работы
У сайта был каталог на несколько сотен позиций и серверный вывод страниц. Нужно было проверить, как поисковые роботы получают контент, какие адреса считаются основными и как сайт представляет сведения о компании и товарах.
Клиент предоставил файлы и дамп базы данных. Основной аудит и правки выполнялись офлайн. Для проверки HTTP-заголовков, кодов ответа и доступности рабочего сайта подготовили отдельный CLI-скрипт для запуска клиентом.
Техническое SEO
Robots.txt, llms.txt, JSON-LD, canonical, sitemap и сжатие ответов.
Обновление окружения
Проверка кода под PHP 8.3 и перенос копии сайта с Evolution 1.4.17 на Evolution 3.5.7.
Что доработали в коде и конфигурации
Robots.txt
Упорядочили правила обхода, ограничения для административной части, служебных каталогов и параметров URL. После повторной проверки оставили общий набор правил без конфликтующих групп для отдельных ботов.
Llms.txt
Подготовили описание компании и навигацию по каталогу и статьям. Ссылки собрали из базы CMS, используя адреса существующих страниц.
Schema.org / JSON-LD
Написали сниппет для генерации Organization, WebSite и BreadcrumbList, а на карточках — Product и Offer. Данные берутся из полей, используемых на самих страницах.
FAQPage формируется только при заполненном поле вопросов и ответов. Обработка ошибок в сниппете позволяет не прерывать вывод страницы при сбое разметки.
Сжатие ответа
Добавили конфигурацию Gzip/Deflate для HTML, CSS, JavaScript, SVG и шрифтов. Проверка фактических HTTP-ответов выделена в сетевой этап аудита.
Что обнаружила повторная проверка
Перед передачей изменений повторно проверили сборку адресов, разметку и правила обхода. Этот этап выявил ошибки как в существующих шаблонах, так и в первой версии новых правок.
Лишний слэш в canonical
Формула в head-чанке добавляла слэш к уже сформированной ссылке. Исправление подготовили для исходного чанка CMS, чтобы оно сохранялось после пересборки кэша.
Повтор домена в JSON-LD
Базовый адрес добавлялся к результату функции, которая уже возвращала полный URL. Исправили сборку ссылок в BreadcrumbList, Product и Offer.
Конфликт групп robots.txt
В первой версии отдельные группы ботов не содержали общих ограничений. Конфигурацию упростили, чтобы запреты для служебных разделов оставались в применяемом наборе правил.
Дубли в sitemap
В карте было 394 записи и 381 уникальный адрес. Шесть URL повторялись от двух до пяти раз. Возможные конфликты документов и alias вынесли в отдельную задачу для проверки в CMS.
Удаление повторов из выгрузки само по себе не решает возможный конфликт документов. Поэтому причину дублей не стали маскировать изменением генератора sitemap.
Что оставили на согласование
На странице контактов видимые телефон и e-mail отличались от значений в ссылках. Актуальные данные должен был подтвердить владелец. До этого подготовленная правка контактов не применялась.
Вопросы и ответы от имени компании также не придумывали: механизм FAQPage подготовили, а его заполнение оставили для реального контента.
Проверка кода под PHP 8.3
Исходная копия работала на Evolution 1.4.17 и PHP 7.2.34. Для проверки обновления использовали второй контур с Evolution 3.5.7 и PHP 8.3. Эти версии относятся к описанному этапу проекта.
Основная группа ошибок находилась в модуле импорта на PHPExcel. Ещё два файла относились к старому обработчику изображений, один — к ядру CMS, заменяемому при обновлении.
Синтаксическая проверка помогла локализовать проблемные компоненты. Проверку поведения приложения, расширений и бизнес-сценариев она не заменяет.
Как проверяли перенос CMS
Старую и новую копии запустили с отдельными базами, портами и томами. Перенос включал настройку подключения к базе, перенос конфигурации, согласование истории миграций со схемой и пересборку служебной иерархии документов.
Что удалось проверить
Проверенные типы страниц на новом стенде возвращали HTTP 200 без фатальных ошибок и предупреждений PHP 8.3 в выводе. Доработки JSON-LD, FAQ-блока и ленивой загрузки изображений сохранились после переноса.
Что осталось нерешённым
Генератор внутренних ссылок выдавал числовые ID вместо человекочитаемых путей. При этом прямые адреса открывались. В собранном кэше отсутствовала карта alias → id.
Следующим шагом была пересборка через административную панель CMS и дальнейшая диагностика при сохранении ошибки. Поэтому результат описан как проверка миграции на стенде, а не как завершённый перенос рабочего сайта.
Результат работы
- Подготовлены изменения robots.txt, llms.txt, JSON-LD, canonical и конфигурации сжатия.
- Выявлены дубли sitemap и расхождения в контактных данных.
- Передан инструмент для сетевой проверки рабочего сайта.
- Проверен синтаксис 947 файлов под PHP 8.3.
- Поднят стенд новой CMS и зафиксирована проблема генерации ссылок.
Отдельно оставались действия на рабочем окружении: применение SQL-миграции, настройка WAF и регистрация в Bing Webmaster Tools. Результат аудита — конкретные правки и перечень следующих шагов с обозначенными ограничениями проверки.
Частые вопросы
Был ли рабочий сайт полностью переведён на PHP 8.3?
В статье описана проверка перехода на отдельном стенде. Проверенные страницы работали, но генерация внутренних ссылок оставалась открытым вопросом. Завершённый перенос рабочего сайта здесь не заявлен.
Что входило в техническую подготовку к AI-поиску?
Правки robots.txt, подготовка llms.txt, генерация JSON-LD из данных CMS, исправление canonical и проверка sitemap. Это работа с кодом и представлением информации на сайте; рост упоминаний в AI-ответах в этом аудите не измерялся.
Зачем проверять плагины отдельно от ядра CMS?
Пользовательские компоненты могут содержать несовместимый код. В этом проекте 18 из 21 файла с синтаксическими ошибками относились к модулю импорта Excel, ещё два — к обработчику изображений.
Что подтверждает синтаксическая проверка 947 файлов?
Она показывает, какие файлы не проходят разбор синтаксиса в выбранной версии PHP. Для проверки реальной работы сайта дополнительно нужны запуск приложения и проверка пользовательских сценариев.
Почему контакты и содержимое FAQ не исправили сразу?
Видимые контакты расходились со значениями ссылок, поэтому требовалось подтверждение владельца. Содержание FAQ не придумывали: подготовили условную генерацию разметки из заполненных данных CMS.
Когда нужна отдельная работа по безопасности и восстановлению?
Если задача связана со взломом, вредоносным кодом или восстановлением функций сайта, её нужно рассматривать отдельно от этого аудита совместимости. Состав таких работ описан на странице услуги безопасности и восстановления сайтов.