Модуль 37

SEO та базові принципи SSR

Ось повноцінний урок, створений у стилі CS50, спеціально для тебе.

🎓 Урок: SEO та чому вашому сайту потрібен SSR?

Привіт, світе! 👋 Мене звати [Твоє Ім'я], і це... ні, не CS50, але ми вчимося з тією ж енергією!

Сьогодні ми поговоримо про те, як зробити так, щоб ваш геніальний веб-сайт не просто існував у вакуумі, а щоб його реально знаходили люди. Ми заглянемо під капотом того, як Google «читає» інтернет, і розберемося, чому ваш красивий React-код може бути невидимим для світу.

Поїхали! 🚀

1. 🔥 Вступ: Проблема «Порожньої Кімнати»

Уявіть собі ситуацію. Ви відкрили найкращу піцерію в місті 🍕. У вас найсмачніше тісто, свіжа моцарела, затишний інтер'єр. Але ви вирішили заклеїти вікна чорною плівкою, а вивіску повісити всередині закладу, в туалеті.

Люди проходять повз. Вони голодні. Але вони не знають, що ви там є.

У веб-розробці це відбувається постійно. Ви створюєте неймовірний сайт на React, Vue або Angular. Ви відкриваєте його в браузері — все літає, анімації плавні, дані завантажуються. Краса! 😍

Але коли Google-бот (або бот Facebook, Telegram, Twitter) заходить на ваш сайт, знаєте, що він бачить?

<div id="root"></div>

Порожнечу. Білий аркуш. Ні заголовків, ни опису піци, ні цін.

❓ Риторичне питання:

Як пошуковик може показати ваш сайт користувачу за запитом "Найкраща піца Київ", якщо він бачить лише порожній <div>?

Спойлер: Ніяк.

Ось тут на сцену виходять SEO (Search Engine Optimization) та SSR (Server-Side Rendering). Без розуміння цього ви будуєте "сайт-привид".

2. 🧠 Теоретична база: Як це працює «під капотом»

Давайте розберемо два світи.

🌍 Світ 1: CSR (Client-Side Rendering) — «Збери сам»

Це стандартний підхід React/Vue. 1. Запит: Браузер каже: "Дай мені сайт". 2. Відповідь сервера: Сервер кидає браузеру майже порожній HTML-файл і важку пачку JavaScript-коду. "Ось інструкція і деталі, збери собі сайт сам". 3. Збірка: Браузер запускає JS, йде за даними (API), малює кнопки. Користувач чекає спінера 🔄.

Аналогія: Ви замовили шафу в IKEA. Вам привезли коробки. Шафи ще немає, поки ви її не зберете.

🌍 Світ 2: SSR (Server-Side Rendering) — «Готова страва»

Це підхід Next.js, Nuxt або старого доброго PHP. 1. Запит: Браузер каже: "Дай мені сайт". 2. Робота сервера: Сервер сам запускає логіку, робить запити до бази даних, формує готовий HTML з текстом і картинками. 3. Відповідь: Сервер віддає повністю готову сторінку. 4. Гідратація (Hydration): JavaScript підвантажується пізніше, щоб кнопки стали клікабельними. Але контент вже є!

Аналогія: Ви замовили піцу. Вам привезли гарячу піцу. Ви можете їсти (читати) одразу, не треба нічого готувати.

🔑 Ключові поняття (Запам'ятай!):

  1. SEO (Search Engine Optimization): Процес покращення сайту, щоб він подобався пошуковим роботам (Googlebot). Роботи люблять текст і швидкість.
  2. Crawler (Павук/Бот): Програма, яка сканує інтернет. Вона заходить на сайт, читає HTML, шукає посилання і йде далі. Вона дуже не любить чекати, поки ваш JavaScript завантажиться.
  3. Meta Tags: Спеціальні теги в <head> (наприклад, <title>, <meta name="description">). Це "бейджик" вашого сайту. Якщо HTML порожній — бейджика немає.

3. 🧪 Приклади: Від невидимого до видимого

Приклад 1: Типовий React (CSR) ❌

Ви написали код. У браузері все працює. Код компонента:

function ProductPage() {
  const [data, setData] = useState(null);

  useEffect(() => {
    fetch('/api/pizza').then(res => res.json()).then(setData);
  }, []);

  if (!data) return <div>Loading...</div>;

  return <h1>{data.name}</h1>; // Тут назва піци
}

Що бачите ви: "Маргарита" 🍕. Що бачить Google (натисніть Ctrl+U або "Переглянути код сторінки"):

<body>
  <div id="root">Loading...</div>
  <script src="main.js"></script>
</body>

Результат: Google думає, що ваш сайт продає "Loading...".

Приклад 2: SSR (Концептуально) ✅

Тут ми готуємо HTML на сервері перед відправкою.

Логіка сервера: 1. Отримав запит /pizza/margarita. 2. Запитав у Бази Даних: "Хто така Маргарита?". 3. Отримав відповідь: { name: "Маргарита", price: 200 }. 4. Вставив це в HTML шаблон. 5. Відправив користувачу.

Що бачить Google:

<body>
  <div id="root">
    <h1>Маргарита</h1>
    <p>Ціна: 200 грн</p>
  </div>
</body>

Результат: Google індексує сторінку за запитом "Маргарита 200 грн". Бінго! 🎉

Приклад 3: Чому посилання в Telegram виглядають погано?

Ви скидаєте другу посилання на свій магазин. * Без SSR: У прев'ю буде загальна назва "Мій Магазин" і стандартна картинка. * З SSR: Сервер динамічно підставить мета-теги Open Graph:

<meta property="og:title" content="Супер Піца Пепероні" />
<meta property="og:image" content="/images/pepperoni.jpg" />

Тепер у Telegram красива картка товару. Це теж частина SEO та Social Sharing.

4. 🛠 Практична частина

Час закачати рукави! Виконайте ці завдання (усно або на папері):

  1. 🔹 Детектив "View Source":

    • Відкрийте будь-який сучасний сайт (наприклад, YouTube або Rozetka).
    • Натисніть праву кнопку миші -> "Переглянути код сторінки" (View Page Source).
    • Спробуйте знайти через пошук (Ctrl+F) текст, який ви бачите на екрані (наприклад, назву першого відео чи товару).
    • Питання: Якщо текст є в коді — це SSR чи CSR? А якщо немає?

  2. 🔹 Задача на логіку:

    • Ви робите Адмін-панель для менеджерів банку. Вхід тільки за паролем. Чи потрібен вам тут SSR для SEO? Чому так або чому ні?

  3. 🔹 Міні-кейс "Блогер":

    • Ваш клієнт — тревел-блогер. Він пише довгі статті про подорожі. Він хоче сайт на React.
    • Яку проблему ви йому створите, якщо зробите звичайний CRA (Create React App)?
    • Як ви поясните йому необхідність використання Next.js (або іншого SSR рішення) простою мовою?

  4. 🔹 А що, якщо...

    • Що, якщо у нас SSR, але база даних відповідає 5 секунд? Що побачить користувач ці 5 секунд? (Білий екран? Чи щось інше?)

5. 💡 Мислення як у розробника

Як думає Senior Developer, коли обирає архітектуру? 🤔

  1. Не все треба "есесерити" (SSR).

    • Помилка новачків: Намагатися зробити SSR для всього.
    • Реальність: SSR навантажує ваш сервер. Для сторінки "Налаштування профілю" SEO не потрібне (Google не має пароля від вашого профілю). Там робимо звичайний CSR. Економимо ресурси!

  2. TTFB (Time to First Byte) — це важливо.

    • Якщо ваш сервер довго генерує сторінку, користувач бачить білий екран довше, ніж при CSR.
    • Порада: Використовуйте кешування. Якщо сторінка "Про нас" не змінюється щохвилини, не генеруйте її щоразу заново.

  3. Google розумнішає, але не ризикуйте.

    • Кажуть, Google вміє виконувати JS. Так, вміє. Але це займає час (rendering queue). Поки він "додумається" відрендерити ваш JS, він вже може проіндексувати ваших конкурентів, у яких чистий HTML. Допоможіть йому допомогти вам.

6. 🧩 Підсумок

Ну що, підсумуємо наш "епізод"?

  • CSR (Client-Side Rendering): Браузер отримує конструктор і будує сайт сам. Добре для додатків (адмінки, дешборди), погано для SEO.
  • SSR (Server-Side Rendering): Сервер віддає готовий HTML. Роботи щасливі, прев'ю в соцмережах красиві.
  • SEO: Це не магія, це просто допомога роботу прочитати ваш контент. Немає контенту в HTML — немає позицій у пошуку.

Тепер ви вмієте: ✅ Розуміти різницю між рендерингом на клієнті та сервері. ✅ Пояснити замовнику, чому його сайт не гуглиться. ✅ Визначати, де потрібен SSR, а де ні.

👀 Тизер наступного уроку: Але чекайте... Якщо SSR навантажує сервер, а сайт новин має 10,000 статей, чи не "ляже" наш сервер від напливу читачів? А що, якщо ми згенеруємо всі ці статті заздалегідь, ще до того, як прийшов перший користувач? На наступному занятті: SSG (Static Site Generation) — або як пекти піцу ще вчора!

Це був CS50... тобто, урок про SEO та SSR. До зустрічі! 👋

← До списку уроків Наступний урок →