В чем разница между SPA и SSR и почему SPA плохо для SEO

Что проверяют

Понимаете ли вы, где собирается HTML и что из этого видят поисковый робот и пользователь в первую секунду. Следом обычно спрашивают, как бы вы починили SEO у существующего SPA и чем SSR отличается от SSG.

Как отвечать

Разница в том, кто собирает разметку:

• SPA: сервер отдаёт почти пустой index.html с <div id="root"> и бандлом, контент рисует JavaScript в браузере, переходы идут через History API без перезагрузки;
• SSR: сервер на каждый запрос рендерит готовый HTML с данными, браузер сразу показывает контент, а после гидратации страница становится интерактивной;
• SSG и ISR: тот же готовый HTML, но собранный заранее на билде или по таймеру, отдаётся с CDN как статика.

Почему SPA проигрывает в SEO. Google умеет исполнять JavaScript, но рендеринг идёт отдельной очередью после обхода, поэтому новые страницы попадают в индекс медленнее, а тяжёлый бандл или упавший запрос к API оставляют роботу пустую страницу. Другие поисковики исполняют JS менее предсказуемо. Боты соцсетей и мессенджеров для превью ссылок JS не запускают вовсе и видят одинаковые <title> и og:* на всех адресах. Ещё одна беда: SPA отвечает 200 на любой путь, и несуществующая страница становится soft 404.

Решения: SSR или SSG через Next.js, Nuxt, SvelteKit, Astro; для легаси SPA пререндер ключевых страниц на билде. Назовите и цену SSR: нагрузка на сервер, время ответа (TTFB) и гидратация, которая на слабых телефонах тоже занимает заметное время.

Где спотыкаются

Говорят «поисковики не видят JavaScript». Это устарело: Google рендерит JS, проблема в задержке, надёжности и других роботах, а не в полной слепоте.

Путают SSR и SSG или считают, что SSR автоматически делает сайт быстрым. Медленный запрос к базе на каждом рендере даёт высокий TTFB, а огромный бандл после гидратации всё так же тормозит интерактивность.

Забывают про метаданные и коды ответа: title, description, canonical, og:image на каждом маршруте и настоящий 404 вместо заглушки с кодом 200.