Безопасный переход с AMP на адаптивный веб-дизайн

Миграция с AMP на адаптивный веб-дизайн включает в себя перенаправление URL-адресов AMP на канонические адаптивные URL-адреса, удаление тегов ссылок rel=”amphtml” и проверку показателей производительности, таких как Largest Contentful Paint (LCP). Владельцы сайтов выполняют этот переход, чтобы упростить обслуживание кода, сохраняя при этом позиции в органическом поиске и скорость загрузки страниц на мобильных устройствах.

Почему издатели отказываются от AMP в пользу адаптивного веб-дизайна?

Ускоренные мобильные страницы (AMP) были внедрены для обеспечения практически мгновенной загрузки на мобильных устройствах путем введения строгих ограничений HTML и кеширования страниц в Google AMP Caches. Со временем современные веб-API и мобильные браузеры значительно продвинулись вперед. Адаптивные макеты, созданные с использованием CSS Grid, flexbox и современных форматов изображений, теперь могут соответствовать или превышать скорость рендеринга ограниченных фреймворков AMP без необходимости поддержки двух отдельных кодовых баз.

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

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

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

Google Search Central

Как подготовить свой сайт перед отключением AMP?

Успешный процесс удаления требует тщательной подготовки для предотвращения битых ссылок, ошибок индексации или потери функций расширенных сниппетов. Перед изменением конфигураций сервера проведите аудит всего вашего инвентаря активных URL-адресов AMP. Системы управления контентом часто добавляют суффиксы /amp/ или ?amp=1 к стандартным постоянным ссылкам, создавая сопряженные шаблоны URL-адресов, которые необходимо идентифицировать.

Проверьте разметку структурированных данных в обоих форматах. Схемы структурированных данных, такие как Article, NewsArticle, Product или BreadcrumbList, должны присутствовать идентично как на странице AMP, так и на канонической целевой странице. Отсутствие разметки схемы на целевой странице может привести к потере улучшений расширенных результатов в поисковой выдаче SERP.

• Проведите аудит всех опубликованных URL-адресов AMP с использованием журналов доступа к серверу и инструментов обхода.
• Убедитесь, что адаптивные целевые страницы содержат идентичные схемы структурированных данных.
• Установите базовые показатели производительности Core Web Vitals для ваших адаптивных шаблонов.
• Убедитесь, что адаптивные мобильные макеты проходят проверки Google на удобство использования на мобильных устройствах.

Пошаговый процесс: как мигрировать с AMP на адаптив?

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

Во-первых, удалите тег rel=”amphtml” из HTML-заголовка ваших канонических адаптивных страниц. Этот тег информирует поисковых роботов о существовании альтернативы AMP. Удаление этого тега сигнализирует поисковым системам, что они больше не должны искать или обнаруживать новые варианты AMP для вашего контента.

Во-вторых, настройте постоянные перенаправления HTTP 301 на вашем веб-сервере или в сети пограничных воркеров (edge workers). Каждый запрос к URL-адресу AMP (например, example.com/article/amp/) должен немедленно отвечать статусом 301, указывающим непосредственно на соответствующий основной адаптивный URL-адрес (example.com/article/). Избегайте временных перенаправлений 302, так как заголовки 301 явно говорят поисковым роботам передать сигналы индексации на новое постоянное назначение.

Для обхода и индексации Поиск Google требует, чтобы страница AMP ссылалась на каноническую страницу.

Google Search Central

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

Как сохранить Core Web Vitals LCP при удалении AMP?

Основным операционным риском при отказе от AMP является падение показателей мобильной скорости, в частности Largest Contentful Paint (LCP). AMP автоматически расставляла приоритеты для главных изображений и откладывала некритические скрипты. При переходе на стандартный адаптивный HTML разработчики должны активно реализовывать эти оптимизации загрузки вручную.

Чтобы удерживать LCP ниже рекомендуемого эталона в 2,5 секунды на мобильных устройствах, явно оптимизируйте основные ресурсы. Используйте синтаксис адаптивных изображений, такие как атрибуты srcset и sizes, чтобы мобильные устройства загружали файлы соответствующего масштаба. Добавьте атрибут fetchpriority=”high” к главному избранному изображению внутри вашего HTML, чтобы указать парсеру браузера немедленно получить его.

Минифицируйте CSS-файлы и инлайньте критические стили области просмотра, чтобы предотвратить задержку блокировки рендеринга. Убедитесь, что веб-шрифты используют font-display: swap для предотвращения появления невидимого текста во время загрузки макета. Эти структурные корректировки позволяют адаптивным шаблонам соответствовать быстрой работе, ранее обеспечиваемой кешами Google AMP.

Распространенные ошибки при выводе страниц AMP из эксплуатации

Многие миграции сайтов страдают от колебаний позиций из-за недочетов при реализации. Избегайте возврата кодов состояния HTTP 404 (Не найдено) или 410 (Удалено) для выведенных из эксплуатации конечных точек AMP. Возврат кодов ошибок заставляет поисковые системы отбрасывать эти URL-адреса без передачи накопленных сигналов ссылок на ваши основные страницы.

• Настройка циклов перенаправления между каноническими конечными точками и конечными точками AMP.
• Использование временных кодов состояния 302 вместо постоянных перенаправлений 301.
• Забывание обновить внутренние ссылки в меню, боковых панелях или нижних колонтитулах, которые указывают на URL-адреса AMP.
• Удаление страниц AMP до подтверждения того, что адаптивные страницы обеспечивают высокую скорость мобильной загрузки.

Как Alien Road применяет миграцию AMP

В Alien Road наш процесс технической реализации вывода AMP из эксплуатации сосредоточен на автоматизированном маппинге, развертывании без простоев и непрерывном отслеживании производительности. В типичном клиентском проекте мы начинаем с извлечения всех проиндексированных URL-адресов AMP непосредственно из файлов журналов сервера и отчетов об индексировании Google Search Console.

Мы создаем программные таблицы перенаправления 1 к 1 внутри правил облачного сервера или пограничных воркеров CDN. Перед отправкой изменений в продакшн наша команда проверяет целостность структурированных данных с помощью инструментов верификации, чтобы обеспечить паритет схем на адаптивных URL-адресах. После развертывания мы отслеживаем повторный обход индексов в течение 60 дней, чтобы подтвердить чистое распределение кодов состояния.

С чего начать миграцию на этой неделе

Начните с инвентаризации вашей текущей настройки AMP. Определите, зависит ли ваш сайт от плагинов CMS или рендеринга пользовательских шаблонов для обслуживания контента AMP. Экспортируйте ваши 100 самых посещаемых мобильных страниц из Google Search Console для мониторинга во время перехода.

Выполните небольшую пилотную миграцию на партии из 10-20 малорисковых страниц. Удалите теги rel=”amphtml” на этих тестовых страницах, разверните серверные перенаправления 301 и повторно отправьте URL-адреса в Search Console. Контролируйте ответ обхода и показатели производительности страницы в течение семи дней перед запуском полномасштабного развертывания по всему сайту.