Автоматизація внутрішньої перелінковки: під ключ для SEO

Наша компанія займається розробкою, підтримкою та обслуговуванням сайтів будь-якої складності. Від простих односторінкових сайтів до масштабних кластерних систем, побудованих на мікро сервісах. Досвід розробників підтверджено сертифікатами від вендорів.

Розробка та обслуговування будь-яких видів сайтів:

Інформаційні сайти або веб-програми
Сайти візитки, landing page, корпоративні сайти, онлайн каталоги, квіз, промо-сайти, блоги, ресурси новин, інформаційні портали, форуми, агрегатори
Сайти або веб-програми електронної комерції
Інтернет-магазини, B2B-портали, маркетплейси, онлайн-обмінники, кешбек-сайти, біржі, дропшиппінг-платформи, парсери товарів
Веб-програми для управління бізнес-процесами
CRM-системи, ERP-системи, корпоративні портали, системи управління виробництвом, парсери інформації
Сайти або веб-програми електронних послуг
Дошки оголошень, онлайн-школи, онлайн-кінотеатри, конструктори сайтів, портали надання електронних послуг, відеохостинги, тематичні портали

Це лише деякі з технічних типів сайтів, з якими ми працюємо, і кожен із них може мати свої специфічні особливості та функціональність, а також бути адаптованим під конкретні потреби та цілі клієнта.

Послуги, які ми пропонуємо
Показано 1 з 1Усі 2062 послуг
Автоматизація внутрішньої перелінковки: під ключ для SEO
Середній
~2-3 дні
Часті запитання

Наші компетенції:

Етапи розробки

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1361
  • image_web-applications_feedme_466_0.webp
    Розробка веб-додатків для компанії FEEDME
    1251
  • image_websites_belfingroup_462_0.webp
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    957
  • image_ecommerce_furnoro_435_0.webp
    Розробка інтернет магазину для компанії FURNORO
    1189
  • image_crm_enviok_479_0.webp
    Розробка веб-додатків для компанії Enviok
    929
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Розробка веб-сайту для компанії ФІКСПЕР
    948

Внутрішня перелінковка: автоматизація, яка працює

Уявіть: на сайті 300 статей, кожна друга — сирота (не має жодного внутрішнього посилання). Google не знаходить ці сторінки, PageRank не тече, користувачі губляться. Ручна перелінковка таких обсягів — праця 3 редакторів на тиждень, а через місяць з'являться 10 нових матеріалів і процес потрібно повторювати. Наш досвід показує: автоматична система окупається за 1–2 місяці.

Ми беремо на себе проєктування та впровадження такої системи — під ключ, з урахуванням вашого стеку. Нижче — як ми це робимо.

Автоматизація вирішує проблему сторінок-сиріт

Сторінки-сироти втрачають трафік і вагу

Без вхідних внутрішніх посилань краулери рідко знаходять такі сторінки, а якщо знаходять — не передають їм посилальну вагу. Результат: низькі позиції, мале охоплення. На одному з проєктів ми виявили, що 40% блогу не мають жодного внутрішнього посилання — після впровадження автоматики трафік на них виріс у 2,5 рази за 3 місяці.

Ручна перелінковка не масштабується

На 500+ сторінках редактор фізично не може пам'ятати всі релевантні зв'язки. Він ставить посилання інтуїтивно, пропускає очевидні пари. Автоматизована система (keyword + semantic) знаходить зв'язки, які людина не помітила б, і робить це за секунди.

Анкори втрачають релевантність

Вручну складно забезпечити, щоб анкор точно відповідав вмісту цільової сторінки. Keyword-matching гарантує: посилання стоїть рівно на тому слові, яке описує сторінку. Semantic matching іде далі — знаходить сторінки за змістом, навіть якщо анкор не збігається.

Чому гібридний підхід ефективніший за один метод?

Ми використовуємо гібридний підхід: keyword-based для прямих входжень, semantic matching для блоку «Схожі статті». Така комбінація дає на 30–60% більше кліків порівняно з використанням лише одного методу.

Keyword-based перелінковка

Збираємо словник ключових слів із заголовків та мета-полів усіх опублікованих статей. Сортуємо за довжиною, щоб довгі ключі перекривалися раніше коротких (уникаємо часткових збігів: "React" всередині "React Native").

class AutoLinker
{
    // Словник: ключове слово → URL
    private array $linkMap;

    public function __construct()
    {
        // Завантажуємо з кешу або з БД
        $this->linkMap = Cache::remember('autolink_map', 3600, function () {
            return Article::where('is_published', true)
                ->get()
                ->flatMap(fn($a) => collect($a->keywords)->mapWithKeys(
                    fn($kw) => [$kw => route('articles.show', $a->slug)]
                ))
                ->all();
        });

        // Сортуємо за довжиною ключового слова (довші спочатку, щоб уникнути часткових збігів)
        uksort($this->linkMap, fn($a, $b) => strlen($b) - strlen($a));
    }

    public function process(string $html, string $currentUrl): string
    {
        $dom = new \DOMDocument();
        @$dom->loadHTML(mb_convert_encoding($html, 'HTML-ENTITIES', 'UTF-8'));

        $linked = []; // Не ставимо одне й те саме посилання двічі

        foreach ($this->linkMap as $keyword => $url) {
            if ($url === $currentUrl) continue;
            if (isset($linked[$url])) continue;

            // Шукаємо лише в текстових нодах, не всередині вже існуючих посилань
            $xpath = new \DOMXPath($dom);
            $textNodes = $xpath->query('//text()[not(ancestor::a) and not(ancestor::code) and not(ancestor::pre)]');

            foreach ($textNodes as $node) {
                $pattern = '/\b' . preg_quote($keyword, '/') . '\b/ui';
                if (preg_match($pattern, $node->nodeValue)) {
                    // Замінюємо лише перше входження
                    $new = preg_replace($pattern,
                        "<a href=\"{$url}\">{$keyword}</a>",
                        $node->nodeValue, 1
                    );

                    $fragment = $dom->createDocumentFragment();
                    @$fragment->appendXML($new);
                    $node->parentNode->replaceChild($fragment, $node);

                    $linked[$url] = true;
                    break;
                }
            }
        }

        return $dom->saveHTML();
    }
}

Після обробки кожна сторінка отримує 3–5 додаткових внутрішніх посилань, які розподіляють вагу рівномірно.

Semantic linking з векторними ембедінгами

Для блоку «Схожі статті» використовуємо векторні ембедінги. При збереженні статті генеруємо ембедінг через OpenAI text-embedding-3-small і зберігаємо в PostgreSQL з розширенням pgvector. Пошук схожих — це запит на косинусну відстань.

class SemanticLinker
{
    public function findRelated(Article $article, int $limit = 5): Collection
    {
        // Попередньо розраховані ембедінги зберігаються в PostgreSQL + pgvector
        return Article::selectRaw('*, embedding <=> ? AS distance', [$article->embedding])
            ->where('id', '!=', $article->id)
            ->where('is_published', true)
            ->whereRaw('embedding IS NOT NULL')
            ->orderBy('distance')
            ->limit($limit)
            ->get();
    }

    // Розрахунок ембедінгу при збереженні статті
    public function generateEmbedding(Article $article): void
    {
        $text = $article->title . "\n" . strip_tags($article->excerpt);

        $response = Http::withToken(config('openai.key'))
            ->post('https://api.openai.com/v1/embeddings', [
                'model' => 'text-embedding-3-small',
                'input' => $text,
            ]);

        $embedding = $response->json('data.0.embedding');
        $article->update(['embedding' => json_encode($embedding)]);
    }
}

Результат: блок схожих статей не за одними тегами, а за реальною смисловою близькістю. Конверсія в клік за такими посиланнями вища на 30–60%.

Компонент «Схожі статті» на React

Готовий UI-компонент, який підвантажує дані з API і відображає у вигляді карток. Потрібен React 18+ і TanStack Query.

// RelatedArticles.tsx
interface Article {
  id: number;
  title: string;
  slug: string;
  excerpt: string;
  category: string;
}

export function RelatedArticles({ articleId }: { articleId: number }) {
  const { data: related } = useQuery({
    queryKey: ['related', articleId],
    queryFn:  () => fetch(`/api/articles/${articleId}/related`).then(r => r.json()),
    staleTime: 5 * 60 * 1000,
  });

  if (!related?.length) return null;

  return (
    <aside className="mt-12 border-t pt-8">
      <h3 className="text-lg font-semibold mb-4">По темі</h3>
      <div className="grid grid-cols-1 sm:grid-cols-2 gap-4">
        {related.map((article: Article) => (
          <a key={article.id} href={`/articles/${article.slug}`}
            className="block p-4 border rounded-lg hover:border-blue-400 transition-colors">
            <span className="text-xs text-blue-600 uppercase tracking-wide">{article.category}</span>
            <h4 className="font-medium mt-1 text-sm leading-snug">{article.title}</h4>
          </a>
        ))}
      </div>
    </aside>
  );
}

Які результати показує гібридний підхід?

Порівняйте ключові метрики до та після впровадження:

Метрика До впровадження Після впровадження
Кількість внутрішніх посилань на сторінку 0–2 5–8
Частка сторінок-сиріт 40% < 5%
CTR у блоці схожих статей 8% 14–18%
Час завантаження сторінки (LCP) 2,3 сек 2,5 сек (незначно)
Кейс: інтернет-магазин з 500 товарами Після впровадження гібридної перелінковки відвідуваність категорій зросла на 35% за 2 місяці, а середня кількість сторінок за сесію збільшилася з 1,8 до 3,2. Окупність системи настала через 1,5 місяці.

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

Компонент Опис Термін
Keyword-based linker Збір словника, заміна в HTML, виключення дублів 1–2 дні
Semantic linker Інтеграція ембедінгів, pgvector, API 3–4 дні
Компонент схожих статей React/Vue компонент, API-роути, кешування 1–2 дні
Звіт про перелінковку SQL-запити для моніторингу orphans, топ incoming 0,5 дня
Документація та навчання Опис процесів, доступ до адмінки 0,5 дня

Разом: 3–7 робочих днів залежно від стеку та складності інтеграції. Зв'яжіться з нами для попередньої оцінки вашого проєкту.

Як ми працюємо

  1. Аналіз — аудит поточної структури, збір семантики, виявлення сторінок-сиріт.
  2. Проєктування — вибір підходу (keyword, semantic або гібрид), архітектура словника, інтеграція з CMS.
  3. Реалізація — написання коду linker'а, налаштування ембедінгів, розробка UI-компонента.
  4. Тестування — перевірка на тестових даних: чи немає поломки верстки, чи не зациклюються посилання, чи коректно працюють виключення.
  5. Деплой та моніторинг — викатка на продакшн, логування помилок, відстеження метрик (кількість посилань, LCP, INP).

Чек-лист: чи готові ви до автоматичної перелінковки?

  • [ ] Усі статті мають унікальні заголовки та мета-описи
  • [ ] У CMS є поле «ключові слова» (або ми можемо додати)
  • [ ] Ваш стек підтримує PHP 8.3+ або Node.js (для ембедінгів)
  • [ ] Є PostgreSQL (для pgvector) або готові перейти

Якщо на всі пункти «так» — впровадження займе 3–5 днів. Якщо ні — ми допоможемо доопрацювати структуру.

Замовте консультацію — ми безкоштовно проаналізуємо ваш сайт, складемо кошторис і скажемо точні терміни.

Чому 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 з потрібними розмірами.
Типовий сценарій 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 пунктів.