Налаштування Prerender.io для SEO SPA: nginx, Express

Ви запустили SPA на Vue 3 — сторінки літають, UX відмінний. Але Googlebot бачить порожній <div id="app">, індексація — нуль. Трафік з пошуку не зростає. У нашій практиці клієнт з інтернет-магазином на Vue 3 після налаштування Prerender.io отримав зростання індексації на 40% за місяць, а LCP впав з 4.2 до 1.1 секунди. Розповідаємо, як налаштувати сервіс правильно і без сюрпризів.

Prerender.io — це SaaS, який за запитом бота рендерить сторінку в headless Chrome і віддає готовий HTML. Для звичайних користувачів нічого не змінюється. Ми використовуємо його в 50+ проектах — від корпоративних сайтів до маркетплейсів. Економія серверного часу порівняно з повноцінним SSR — до 70%, а навантаження на сервер знижується в 3–5 разів.

Проблеми, які вирішуємо

SPA за замовчуванням не віддають контент при вимкненому JavaScript — пошукові боти бачать порожній index.html. У результаті:

• Сторінки не потрапляють у видачу (або потрапляють з помилками).
• Сніпети порожні, Title — "React App".
• Внутрішні посилання не індексуються.

Наприклад, клієнт з каталогом на 10 000 товарів: без prerender боти індексували лише 12 сторінок з 10 000. Після налаштування — 8 500 сторінок за тиждень.

Типові помилки:

• nginx не розрізняє ботів і людей.
• Middleware неправильно фільтрує User-Agent.
• Кеш не скидається після деплою.

У 90% випадків проблема саме у фільтрації User-Agent. Ми налаштовуємо Prerender.io з урахуванням цих нюансів — так, щоб боти отримували повний HTML, а користувачі — швидкий SPA.

Чому Prerender.io, а не повноцінний SSR?

SSR (Nuxt 3, Next.js) рендерить кожну сторінку на сервері — це навантаження і складність. Prerender.io робить це тільки для ботів: витрачає ресурси тільки на рендеринг для пошуковиків. Економія серверного часу — до 70% порівняно з SSR. Плюс не потрібно переписувати фронтенд — підходить для будь-якого SPA-фреймворку. На практиці Prerender.io знижує навантаження на сервер у 3–5 разів для проектів з високим трафіком, особливо якщо більша частина сторінок статична.

Як це працює (схематично)

1. Бот запитує /products/42.
2. nginx / middleware визначає User-Agent і проксіює на prerender.io.
3. Prerender.io рендерить сторінку в headless Chrome.
4. Повертає готовий HTML боту.

Користувачі отримують звичайний SPA — жодних змін.

Налаштування Prerender.io для SPA

Налаштування nginx

map $http_user_agent $prerender_ua {
    ~*(Googlebot|AdsBot-Google|Googlebot-Image|Bingbot|Slurp|
       DuckDuckBot|Baiduspider|YandexBot|LinkedInBot|
       facebookexternalhit|Twitterbot|WhatsApp|TelegramBot)  "1";
    default "0";
}

server {
    listen 443 ssl;
    server_name company.com;

    location / {
        if ($prerender_ua = "1") {
            rewrite .* /$scheme://$host$request_uri? break;
            proxy_pass https://service.prerender.io;
            proxy_set_header X-Prerender-Token "YOUR_API_TOKEN";
            proxy_set_header X-Prerender-Host $host;
            proxy_connect_timeout 5s;
            proxy_read_timeout 60s;
        }

        try_files $uri /index.html;
    }
}

Middleware для Node.js (Express)

const prerender = require('prerender-node')

prerender.set('prerenderToken', process.env.PRERENDER_TOKEN)
prerender.set('prerenderServiceUrl', 'https://service.prerender.io/')

// Опціональні налаштування
prerender.crawlerUserAgents.push('TelegramBot', 'WhatsApp')
prerender.set('blacklistPaths', ['/admin', '/dashboard', '/api'])

app.use(prerender)

Бібліотека prerender-node доступна на GitHub.

Як налаштувати автоматичний рекеш при деплої?

Prerender.io кешує сторінки автоматично. Але після деплою кеш потрібно скидати для змінених URL. Ми автоматизуємо це через API:

# Очистити конкретний URL
curl -X POST https://api.prerender.io/recache \
  -H "Content-Type: application/json" \
  -d '{"prerenderToken": "YOUR_TOKEN", "url": "https://company.com/product/42"}'

# Рекешувати при деплої (список змінених URL)
CHANGED_URLS=$(git diff HEAD~1 --name-only | grep "pages/" | ...)
for url in $CHANGED_URLS; do
  curl -X POST https://api.prerender.io/recache \
    -d "{\"prerenderToken\": \"$TOKEN\", \"url\": \"https://company.com/$url\"}"
done

Якщо сторінок багато — використовуємо прекеш по sitemap:

import requests
import xml.etree.ElementTree as ET

def precache_sitemap(sitemap_url, prerender_token):
    response = requests.get(sitemap_url)
    root = ET.fromstring(response.content)
    ns = {'sm': 'http://www.sitemaps.org/schemas/sitemap/0.9'}

    urls = [loc.text for loc in root.findall('.//sm:loc', ns)]
    print(f"Precaching {len(urls)} URLs...")

    for url in urls:
        requests.post('https://api.prerender.io/recache',
                     json={'prerenderToken': prerender_token, 'url': url})

precache_sitemap('https://company.com/sitemap.xml', os.environ['PRERENDER_TOKEN'])

Prerender.io зберігає кеш на своїх серверах. Термін життя кешу за замовчуванням — 30 хвилин, його можна налаштувати через заголовки Cache-Control. Рекомендуємо ставити max-age=3600 для статичних сторінок і no-cache для динамічних. Автоматичний рекеш при деплої гарантує, що боти побачать актуальну версію.

Як перевірити, що prerender працює?

# Запит як Googlebot
curl -A "Googlebot/2.1 (+http://www.google.com/bot.html)" \
  https://company.com/products/iphone-15 | \
  grep -o '<title>[^<]*</title>'

# Має повернути реальний title, не "React App" або порожній рядок

Chrome DevTools → Network → Disable JS → перезавантажити сторінку — якщо контент видно без JS, prerendering працює коректно для ботів.

Які переваги Prerender.io для SPA?

Швидке впровадження — налаштування займає від 0,5 дня. Не потребує переписування коду. Економія серверних ресурсів до 70%. Середній час першого рендеру холодної сторінки — 1.5 секунди, гарячої — 100 мс. Prerender.io підтримує всі популярні фреймворки: Vue, React, Angular.

Вартість базового плану Prerender.io становить $99 на місяць для 10 000 запитів. Економія на серверних ресурсах може досягати $500–$1000 на місяць порівняно з виділеним SSR-сервером. За даними документації Prerender.io, середній час окупності інтеграції — 2 місяці.

Що входить у налаштування під ключ

Терміни та вартість

Базове налаштування (nginx + прекеш) — від 0,5 до 1 робочого дня. Складна інтеграція (кілька middleware, кастомний рекеш) — до 2 днів. Вартість фіксована і розраховується індивідуально. Ми гарантуємо, що після налаштування Googlebot почне бачити контент. Наша команда має 5 років досвіду і виконала понад 50 проектів з SEO-оптимізації SPA.

Замовте налаштування Prerender.io — отримайте консультацію інженера. Зв'яжіться з нами, щоб обговорити ваш проект. Отримайте консультацію інженера — ми допоможемо обрати оптимальне рішення.

Чому 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 на мобільному з'єднанні — це фізично повільно.

Рішення по кроках:

1. Переносимо hero з CSS background в <img> з fetchpriority="high" та loading="eager"
2. Конвертуємо в WebP, додаємо srcset: 800w для мобільних, 1400w для десктопа
3. <link rel="preload" as="image" href="hero-800.webp" media="(max-width: 768px)"> в <head>
4. Прибираємо всі 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 з потрібними розмірами.

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) — сигнал якості.

Що входить в роботу

• Документація: звіт зі знайденими проблемами, roadmap за пріоритетами, таймінги для кожного етапу.
• Доступи: налаштування моніторингу (SpeedCurve, Sentry Search Console), передача dashboard.
• Навчання: розбір типових помилок для вашої команди (1–2 дзвінки).
• Підтримка: супровід протягом місяця після деплою — перевірка метрик, фікс регресій.

Зв'яжіться з нами — ми оцінимо ваш проект за 2 дні і покажемо, скільки позицій можна повернути за рахунок технічного SEO. Досвід роботи з проектами рівня сотень тисяч відвідувань на місяць — гарантуємо вимірний результат в Core Web Vitals до/після. Замовте аудит у цій формі — отримайте персональний чек-лист з 15 пунктів.