Типова ситуація: клієнт скаржиться, що мобільна версія сайту завантажується 8 секунд, LCP зашкалює за 8 секунд, а трафік з Google падає на 30%. Одне з рішень — впровадження AMP-сторінок за специфікацією Google. AMP (Accelerated Mobile Pages) — відкритий стандарт, який гарантує завантаження менше 1 секунди за рахунок кешування в CDN Google. Згідно з Google AMP документацією, Core Web Vitals (LCP, CLS, INP) на таких сторінках практично завжди в зеленій зоні, що безпосередньо впливає на ранжування та конверсію. Наш досвід показує: після впровадження AMP-версій для статей блогу конверсія з мобільних пристроїв зростає на 15–25%, а показник відмов знижується вдвічі, що в перерахунку на рекламний бюджет може економити від 20 000 до 50 000 гривень щомісяця. Ми виконаємо верстку AMP під ключ з повною валідацією та безшовною інтеграцією у ваш проект. Нижче розберемо ключові технічні аспекти: структуру документа, заміну HTML-тегів AMP-компонентами, валідацію та типові помилки.
Коли AMP необхідний?
AMP має сенс для:
- Новинних статей та блог-постів (AMP Story)
- Лендінгів (AMP Email, AMP for Ads)
- Сторінок з високою часткою мобільного трафіку з пошуку
AMP недоцільний для інтерактивних додатків, кошиків інтернет-магазинів та сторінок з важкою логікою. Якщо у вас контентний проект з великим мобільним трафіком, AMP — ваш вибір.
Як AMP пришвидшує завантаження сторінок?
AMP-сторінки завантажуються в середньому в 4 рази швидше за звичайні. Це досягається за рахунок:
- Кешування в Google AMP Cache (CDN, розташований поруч із користувачем)
- Заборони на блокуючий рендеринг JavaScript
- Примусового вказання розмірів медіаелементів (запобігає reflow)
| Метрика |
Звичайна сторінка |
AMP-сторінка |
| Час завантаження (LCP) |
3-5 с |
0.5-1 с |
| Сукупне зміщення макету (CLS) |
0.1-0.3 |
<0.05 |
| TTFB |
0.5-1 с |
0.1-0.2 с (з кешу) |
Структура та обмеження AMP-документа
<!doctype html>
<html ⚡ lang="uk">
<head>
<meta charset="utf-8">
<script async src="https://cdn.ampproject.org/v0.js"></script>
<title>Заголовок статті</title>
<link rel="canonical" href="https://example.com/article">
<meta name="viewport" content="width=device-width,minimum-scale=1">
<script type="application/ld+json">
{"@context":"https://schema.org","@type":"NewsArticle",...}
</script>
<style amp-boilerplate>body{...}</style>
<noscript><style amp-boilerplate>body{...}</style></noscript>
<style amp-custom>
/* Максимум 75KB CSS. Звичайний CSS, жодних @import */
body { font-family: 'Roboto', sans-serif; }
.article-header { font-size: 2rem; }
</style>
</head>
<body>
<amp-img src="/hero.jpg" width="1200" height="630" layout="responsive" alt="AMP-сторінка із зображенням"></amp-img>
<article>
<h1>Заголовок</h1>
<p>Текст статті...</p>
</article>
</body>
</html>
Ключові обмеження:
- Немає
<script> користувацьких тегів — тільки AMP-компоненти (<amp-script> з обмеженнями)
- CSS не більше 75KB — все inline, жодних зовнішніх таблиць
-
<img> заборонений — тільки <amp-img> з явними width/height
- Inline стилі (
style="") — заборонені, лише через <style amp-custom>
- Форми — через
<amp-form>, не стандартний <form>
Заміна HTML-тегів AMP-компонентами
| HTML |
AMP-аналог |
<img> |
<amp-img> |
<video> |
<amp-video> |
<iframe> |
<amp-iframe> |
| Карусель |
<amp-carousel> |
| Аккордеон |
<amp-accordion> |
| Аналітика |
<amp-analytics> |
Замість <img> використовується <amp-img> з обов'язковим атрибутом alt (наприклад, alt="AMP-компонент").
Canonical та зв'язок із звичайною версією
У кожної статті — дві версії: звичайна та AMP. Зв'язуються через:
<!-- У звичайній сторінці -->
<link rel="amphtml" href="https://example.com/article?amp=1">
<!-- В AMP-сторінці -->
<link rel="canonical" href="https://example.com/article">
Google показує AMP-версію в пошуку (з блискавкою ⚡), завантажуючи з кешу.
Валідація AMP: покрокова інструкція
- Відкрийте сторінку в браузері з розширенням AMP Validator.
- Перевірте через онлайн-інструмент validator.ampproject.org.
- Використовуйте CLI:
npx @ampproject/toolbox-cli validate https://example.com/article.
- Виправте всі помилки та повторіть перевірку.
Приклад помилки: The attribute 'style' is disallowed. — означає, що використано inline-стиль, який заборонено. Перенесіть стиль у <style amp-custom>.
Процес верстки AMP під ключ
-
Аудит поточних сторінок: аналізуємо мобільну продуктивність, виявляємо кандидатів для AMP.
- Проектування шаблону: створюємо AMP-сумісний макет з урахуванням обмежень.
- Розробка: верстка компонентів, інтеграція з CMS (WordPress, Drupal, Strapi).
- Валідація та тестування: перевіряємо через всі інструменти, домагаємося зеленого статусу.
- Деплой: розміщуємо AMP-версії, налаштовуємо канонічні посилання.
Що входить у роботу
- Розробка AMP-шаблону для одного типу сторінок (стаття, лендінг)
- Налаштування генерації AMP з CMS (якщо застосовно)
- Повний звіт з валідацією
- Інтеграція аналітики через
<amp-analytics>
- Коротка документація з підтримки
Вартість типового проекту — від 15 000 до 30 000 гривень за шаблон одного типу сторінок. Оцінимо ваш проект за 1 день після отримання брифу. Замовте верстку AMP-сторінок та отримайте консультацію наших інженерів.
Типові помилки при верстці AMP
- Використання
<img> замість <amp-img> — одна з найчастіших причин невалідності.
- Забутий
layout="responsive" — без нього медіа може вилізти за межі.
- Inline-стилі (
style="") — AMP їх забороняє, все тільки через блок <style amp-custom>.
- Відсутність viewport meta — обов'язковий.
Приклад поширеної помилки
Часто розробники забувають додати layout="responsive" для зображень. Без нього медіаелемент може вийти за межі контейнера, але валідатор не завжди це ловить. Результат — неочікуване зміщення макету на мобільних. Завжди перевіряйте наявність layout.
Наша команда має більше 5 років досвіду верстки AMP та реалізувала 15+ проектів з нульовими помилками валідації. Ми гарантуємо відповідність специфікації та допомогу при подальшому розвитку.
Чому Core Web Vitals критичні для технічного SEO
PageSpeed показує 34/100 на мобільних. У Search Console — червоні метрики по всіх сторінках категорій. Конкурент із сайтом на 3 роки старше стоїть вище у видачі, незважаючи на слабші тексти. Технічна продуктивність стала прямим ранжуючим фактором — і розрив між «прийнятно» та «швидко» коштує позицій. Ми вирішували цю проблему для десятків проектів — від інтернет-магазинів до SaaS-платформ — і знаємо, які помилки з'їдають ранжування.
Як досягти хороших показників Core Web Vitals?
Core Web Vitals: що реально впливає на позиції
Google використовує три метрики як сигнали ранжування (Page Experience): LCP (Largest Contentful Paint), CLS (Cumulative Layout Shift), INP (Interaction to Next Paint, замінив FID з останнього великого оновлення алгоритму).
LCP: чому 8 секунд — це не проблема зображення
LCP вимірює час відмальовки найбільшого видимого елемента сторінки. Найчастіше — hero image або H1. Пороги: добре < 2.5s, погано > 4s.
Типовий діагноз на реальному проекті: інтернет-магазин одягу, LCP 7.8s на мобільних. Елемент — hero image категорії, 4.2MB JPEG без srcset, завантажується через CSS background-image (не <img>). Проблема подвійна: по-перше, браузер не може preload CSS background images через <link rel="preload"> стандартним способом. По-друге, 4.2MB на мобільному з'єднанні — це фізично повільно.
Рішення по кроках:
- Переносимо hero з CSS background в
<img> з fetchpriority="high" та loading="eager"
- Конвертуємо в WebP, додаємо
srcset: 800w для мобільних, 1400w для десктопа
-
<link rel="preload" as="image" href="hero-800.webp" media="(max-width: 768px)"> в <head>
- Прибираємо всі render-blocking скрипти вище hero через
defer
Підсумок: LCP 7.8s → 1.9s. Без зміни хостингу, без CDN.
Якщо LCP — не зображення, а текстовий блок: проблема може бути в TTFB (повільний сервер), в render-blocking CSS/JS, або в web fonts з font-display: block.
CLS: зсуви, які дратують користувача і Google
CLS вимірює сумарний зсув елементів в процесі завантаження. Пороги: добре < 0.1, погано > 0.25. CLS 0.35 — це банер, який з'являється через секунду і зсуває весь вміст сторінки вниз.
Джерела CLS:
- Зображення без заданих розмірів.
<img src="photo.jpg"> без width і height — браузер не резервує місце, контент стрибає при завантаженні. Фікс: явні width/height або aspect-ratio в CSS.
- Рекламні блоки та віджети. Google Ads, чат-віджети, cookie consent — все, що з'являється після основного контенту. Рішення: резервувати місце через
min-height або завантажувати до рендеру основного контенту.
- Web fonts. FOUT (Flash of Unstyled Text) та FOIT (Flash of Invisible Text) можуть викликати переформатування.
font-display: swap з size-adjust (CSS властивість для вирівнювання розмірів fallback шрифту) мінімізує CLS.
- Динамічний контент. Якщо блок з'являється після завантаження (fetch даних, lazy load) — додаємо skeleton placeholder з потрібними розмірами.
| Типовий сценарій |
CLS до |
CLS після |
Основний фікс |
Банер знижок без min-height |
0.42 |
0.02 |
min-height: 300px |
| Картинки в статтях без атрибутів |
0.18 |
0.01 |
width/height + aspect-ratio |
| Віджет чату, що завантажується через 3с |
0.35 |
0.05 |
position: fixed із зарезервованим відступом |
INP: чому інтерфейс «зависає» на 500ms
INP вимірює затримку відповіді на будь-яку взаємодію користувача: клік, тап, введення. Пороги: добре < 200ms, погано > 500ms. INP 680ms — це коли користувач натискає кнопку фільтра, а нічого не відбувається півсекунди.
Головна причина високого INP — заблокований main thread. JavaScript-бандл 2.1MB парситься і виконується синхронно. Поки виконується, користувацькі події не обробляються.
Діагностика через Chrome DevTools → Performance → взаємодія з підозрілою затримкою → знайти Long Tasks (> 50ms). Типові винуватці:
- Безперервна обробка великого списку без
requestIdleCallback або requestAnimationFrame
- Важкі event listeners без
debounce/throttle
- Синхронний setState в React, який тригерить повний ре-рендер складного дерева компонентів
- Third-party scripts: livechat, аналітика, віджети — вони виконуються в тому ж main thread
Рішення: code splitting через динамічний import(), перенесення важких обчислень в Web Workers, React.memo + useMemo для запобігання зайвих ре-рендерів, scheduler API для пріоритизації задач.
Schema.org: розмітка, яку читають роботи
Структуровані дані через JSON-LD — не прямий ранжуючий фактор, але дають rich snippets у видачі (зірки рейтингів, ціни, дата публікації), що збільшує CTR на 20–30%.
Типи розмітки за сценаріями:
-
E-commerce:
Product з offers (ціна, наявність, валюта), aggregateRating (рейтинг з відгуків), brand. BreadcrumbList для навігації. ItemList для сторінок категорій.
-
Статті та блог:
Article або BlogPosting з author, datePublished, dateModified, image. Organization та WebSite на головній сторінці — допомагають Google пов'язати сайт з брендом.
-
Локальний бізнес:
LocalBusiness з address, telephone, openingHours, geo. Критично для локального SEO.
-
FAQ:
FAQPage з mainEntity — питання та відповіді можуть з'являтися прямо у видачі як розкривний блок.
Валідація: Google Rich Results Test та Schema Markup Validator. Часта помилка — вказати price без priceCurrency, або ratingValue без reviewCount. Google ігнорує неповну розмітку.
Як проводити технічний SEO-аудит
Сканованість. robots.txt блокує потрібні сторінки (або навпаки, не блокує службові). Canonical URLs налаштовані неправильно — дублюються сторінки з UTM-мітками. Sitemap містить сторінки з noindex. Все це Screaming Frog або Sitebulb покажуть за годину сканування.
Core Web Vitals в масштабі. Google Search Console → Core Web Vitals → дивимося не окремі сторінки, а групи URL (шаблон сторінки продукту, шаблон категорії, блог). Проблема зазвичай системна — одна помилка в шаблоні псує сотні сторінок.
JavaScript SEO. Google рендерить JavaScript, але з затримкою (іноді дні для повного рендеру). Для критичного контенту — SSR або SSG обов'язкові. Перевіряємо через Search Console → Inspect URL → View Crawled Page: що бачить Googlebot.
Internal linking. Орфанні сторінки (немає вхідних внутрішніх посилань) втрачають PageRank. Бите посилання (404) — сигнал якості.
Типові помилки при впровадженні Schema.org
- Вказано
price без priceCurrency — розмітка ігнорується.
-
ratingValue без reviewCount — у видачі не показується.
- Кілька
Product на одній сторінці без @type: ItemList — Google бере тільки перший.
- JSON-LD в GTM — Google не завжди бачить динамічну розмітку, краще серверний рендеринг.
| Етап роботи |
Що входить |
Термін |
| Аудит |
Сканування, аналіз Core Web Vitals, аудит Schema, звіт з пріоритетами |
1–2 тижні |
| Оптимізація одного шаблону |
LCP, CLS, INP, впровадження SSR/SSG, налаштування preload |
2–4 тижні |
| Повна технічна оптимізація |
Всі шаблони, code splitting, Web Workers, моніторинг в CI |
4–10 тижнів |
| Впровадження Schema.org |
JSON-LD генерація, валідація, тестування rich snippets |
1–3 тижні |
Що входить в роботу
- Документація: звіт зі знайденими проблемами, roadmap за пріоритетами, таймінги для кожного етапу.
- Доступи: налаштування моніторингу (SpeedCurve, Sentry Search Console), передача dashboard.
- Навчання: розбір типових помилок для вашої команди (1–2 дзвінки).
- Підтримка: супровід протягом місяця після деплою — перевірка метрик, фікс регресій.
Зв'яжіться з нами — ми оцінимо ваш проект за 2 дні і покажемо, скільки позицій можна повернути за рахунок технічного SEO. Досвід роботи з проектами рівня сотень тисяч відвідувань на місяць — гарантуємо вимірний результат в Core Web Vitals до/після. Замовте аудит у цій формі — отримайте персональний чек-лист з 15 пунктів.
