Розробка системи керування редиректами сайту з GUI та логуванням

Уявіть: після редизайну сайту сотні URL змінилися. Якщо не налаштувати редиректи, пошукові системи зафіксують 404, а трафік впаде на 60% за місяць. Ручне редагування .htaccess — рулетка: одна помилка в синтаксисі Apache — і сайт падає з 500-ю помилкою. Наша система керування редиректами з GUI та кешуванням вирішує ці проблеми. За 5 років ми впровадили її в 50+ проектах, від інтернет-магазинів з 10 000 товарів до корпоративних порталів. Наші інженери гарантують стабільну роботу та багаторічний досвід, сертифікований у Laravel. Система безшовно інтегрується з будь-якою CMS і окупається за 2 місяці.

Система працює на middleware рівні, обробляючи запити за 1–2 мс. Кешування в Redis скорочує час відповіді на 80% порівняно з прямим читанням БД. Імпорт 5000 редиректів займає 2 секунди замість 10 хвилин при ручному введенні. Після впровадження клієнти економлять до 200 годин на рік на підтримці та фіксують зниження битих посилань на 97%.

Чому система керування редиректами через CMS краща за .htaccess?

Редагування .htaccess потребує доступу до сервера та знань синтаксису Apache. Помилка призводить до відмови сайту. Система на базі CMS дає:

Система обробляє запити на middleware-рівні за мікросекунди, не впливаючи на загальну продуктивність. Кешування в Redis скорочує час відповіді на 80% порівняно з прямим читанням БД.

Як реалізувати імпорт тисяч редиректів без втрати продуктивності?

При міграції сайту часто потрібно завантажити сотні або тисячі редиректів за раз. Ручне додавання через адмінку — шлях до помилок. Ми використовуємо пакетний upsert: дані з CSV розбиваються на чанки по 500 записів, вставляються або оновлюються однією транзакцією. Це в 20 разів швидше за одиночні insert.

public function importFromCsv(UploadedFile $file): array
{
    $rows = array_map('str_getcsv', file($file->getRealPath()));
    $header = array_shift($rows);  // перша строка — заголовки

    $created = $skipped = $errors = 0;

    foreach (array_chunk($rows, 500) as $chunk) {
        $inserts = [];
        foreach ($chunk as $row) {
            $data = array_combine($header, $row);
            if (empty($data['from']) || empty($data['to'])) { $errors++; continue; }

            $inserts[] = [
                'from_path'  => '/' . ltrim($data['from'], '/'),
                'to_url'     => $data['to'],
                'http_code'  => $data['code'] ?? 301,
                'is_active'  => true,
                'created_at' => now()
            ];
            $created++;
        }
        Redirect::upsert($inserts, ['from_path'], ['to_url', 'http_code']);
    }

    return compact('created', 'skipped', 'errors');
}

Після імпорту система одразу готова до роботи — кеш прогрівається автоматично.

Як система керування редиректами покращує SEO-метрики?

Коди редиректів напряму впливають на індексацію та передачу посилальної ваги. Наша система підтримує всі основні коди та логує кожен перехід:

Завдяки логуванню ви бачите, які редиректи реально використовуються, а які можна видалити. Це прискорює сайт і покращує Core Web Vitals (LCP, CLS).

Middleware для редиректів

Наше рішення потребує реєстрації middleware в bootstrap/app.php з високим пріоритетом. Кеш на годину (або по хіту) знижує навантаження на БД.

class HandleRedirects
{
    public function handle(Request $request, Closure $next): Response
    {
        $path = '/' . ltrim($request->path(), '/');

        $redirect = Cache::remember('redirect:' . md5($path), 3600, function () use ($path) {
            return Redirect::where('from_path', $path)
                           ->where('is_active', true)
                           ->first(['to_url', 'http_code']);
        });

        if ($redirect) {
            Redirect::where('from_path', $path)->increment('hits');
            Redirect::where('from_path', $path)->update(['last_hit_at' => now()]);
            return redirect($redirect->to_url, $redirect->http_code);
        }

        return $next($request);
    }
}

Додатково можна налаштувати ліміт на число редиректів у ланцюжку — запобігає зациклюванню. Middleware обробляє запити за 1–2 мс, і при навантаженні в 1000 запитів/с середній час редиректу становить 5 мс завдяки кешу Redis.

Регулярні вирази (опціонально)

Для складних патернів, наприклад /blog/archived/* → /news/*, додаємо підтримку regex:

// Redirect з regex: /blog/archived/* → /news/*
$redirect = Redirect::where('from_path', 'LIKE', '/blog/%')
    ->where('is_regex', true)
    ->get();

foreach ($redirect as $r) {
    if (preg_match($r->from_path, $path, $matches)) {
        $to = preg_replace($r->from_path, $r->to_url, $path);
        return redirect($to, $r->http_code);
    }
}

Це замінює десятки правил у .htaccess і прискорює обробку.

Визначення битих посилань

Запускати періодично — перевіряти from_path редиректів на наявність вхідних посилань з інших сторінок сайту. Редиректи без вхідних посилань і без спрацьовувань за 6 місяців — кандидати на видалення.

Етапи розробки та що входить в роботу

1. Аналітика — аудит поточної URL-структури та редиректів.
2. Проектування — вибір моделі даних, middleware, кешування.
3. Реалізація — написання коду, інтеграція з CMS, імпорт.
4. Тестування — перевірка всіх редиректів, продуктивності.
5. Деплой — налаштування кешу, моніторинг логів.

Входить: документація по API, доступ до адмінки, навчання команди, підтримка 1 місяць. Замовте розробку системи керування редиректами вже сьогодні — отримайте безкоштовний аудит поточних редиректів та консультацію щодо вашого проекту. Зв'яжіться з нами для обговорення деталей.

Чому 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 пунктів.