Оптимізація внутрішньої перелінковки: аудит структури сайту

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

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

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

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

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

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

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

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

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

При аудиті великого інтернет-магазину (100 000 сторінок) ми виявили 40% сторінок без вхідних внутрішніх посилань — класичні orphan pages. Роботи Google їх не знаходили, сторінки не індексувалися. Після реструктуризації перелінковки та додавання зв’язків Index coverage зріс з 60% до 95% за два тижні. Органічний трафік додав 22%. Цей кейс типовий: проблема криється в неправильній внутрішній перелінковці (Internal Linking Structure). Без неї навіть якісний контент залишається непоміченим. У статті розберемо, як провести аудит, виправити помилки та побудувати систему, яка прискорить індексацію та підвищить авторитет сторінок. Для оптимізації структури сайту ми використовуємо краулери, будуємо граф переходів та аналізуємо розподіл PageRank. За даними PageRank, правильна перелінковка покращує краулінговий бюджет і знижує глибину сканування на 50%. Далі розглянемо покроковий план.

Визначення Internal Linking Structure та її важливість для SEO

Internal Linking Structure — це каркас посилань між сторінками. Вона визначає, які сторінки отримують більше ваги, а які залишаються в тіні. Google використовує внутрішні посилання для виявлення контенту та розподілу авторитету. Помилки: orphan pages, глибока вкладеність, монотонний anchor text. Кожна з них знижує ефективність SEO. Наприклад, для сайту з 10 000 сторінок кожне нове внутрішнє посилання на orphan page може збільшити її видимість на 15–20%.

Як виявити orphan pages та оцінити розподіл PageRank?

Для аналізу використовуємо краулер на Scrapy та будуємо граф переходів. Наведений нижче код збирає всі внутрішні посилання, розраховує PageRank та виводить список orphan pages.

Код для аналізу
import scrapy
import networkx as nx

class InternalLinksSpider(scrapy.Spider):
    name = 'internal_links'
    start_urls = ['https://company.com']

    def __init__(self):
        self.graph = nx.DiGraph()

    def parse(self, response):
        current_url = response.url

        for link in response.css('a[href]::attr(href)').getall():
            absolute = response.urljoin(link)
            if 'company.com' in absolute:
                self.graph.add_edge(current_url, absolute)
                yield response.follow(absolute, self.parse)

    def closed(self, reason):
        pagerank = nx.pagerank(self.graph)
        top_pages = sorted(pagerank.items(), key=lambda x: x[1], reverse=True)[:20]
        orphans = [node for node in self.graph.nodes()
                   if self.graph.in_degree(node) == 0
                   and node != 'https://company.com']

        print(f"Orphan pages: {len(orphans)}")
        for url in orphans[:10]:
            print(f"  {url}")

Після прогону отримуємо ключові метрики: orphan pages, crawl depth, розподіл PageRank. Важливі сторінки повинні бути на глибині не більше 3 кліків від головної.

Які переваги плоскої ієрархії над глибокою?

Глибока вкладеність (5+ кліків) змушує роботів витрачати краулінговий бюджет на другорядні сторінки. Плоска структура (1-3 кліки до будь-якої важливої сторінки) прискорює індексацію вдвічі порівняно з глибокою та передає більше ваги. Плоска ієрархія в 2 рази краща за глибоку за швидкістю індексації та розподілом PageRank. Порівняйте:

Тип ієрархії Глибина Вплив на індексацію
Плоска 1-3 кліки Швидка індексація, високий PageRank
Глибока 5+ кліків Повільна індексація, втрата ваги

Приклад:

Головна → Категорія → Товар (максимум 3 кліки)

Замість:

Головна → Категорія → Підкатегорія → Підпідкатегорія → Товар (5 кліків)

Як реалізувати хлібні крихти?

Хлібні крихти — це автоматична система внутрішніх посилань. Важливо додати Schema.org розмітку для структурованих даних:

<nav aria-label="breadcrumb">
  <ol itemscope itemtype="https://schema.org/BreadcrumbList">
    <li itemprop="itemListElement" itemscope itemtype="https://schema.org/ListItem">
      <a itemprop="item" href="/"><span itemprop="name">Головна</span></a>
      <meta itemprop="position" content="1">
    </li>
    <li itemprop="itemListElement" itemscope itemtype="https://schema.org/ListItem">
      <a itemprop="item" href="/catalog/phones"><span itemprop="name">Телефони</span></a>
      <meta itemprop="position" content="2">
    </li>
  </ol>
</nav>

Хлібні крихти дають користувачу контекст, а пошуковим системам — чітку структуру сайту. Це покращує поведінкові фактори та клікабельність у видачі на 30% порівняно з сайтами без них.

Як покращити anchor text?

Anchor text має бути інформативним. Замість «тут» або «натисніть» використовуйте ключові слова. Порівняйте:

Тип anchor Приклад Оцінка
Generic тут Погано
Brand Company Нейтрально
Keyword-rich посібник з SEO Добре

Перевірити різноманітність можна за допомогою скрипту:

def analyze_anchors(graph_edges):
    anchor_distribution = {}
    for source, target, data in graph_edges:
        anchor = data.get('anchor', '').lower()
        if target not in anchor_distribution:
            anchor_distribution[target] = []
        anchor_distribution[target].append(anchor)

    for url, anchors in anchor_distribution.items():
        if len(set(anchors)) == 1 and len(anchors) > 3:
            print(f"Monotonous anchors for {url}: '{anchors[0]}'")

Виправлення orphan pages

Після виявлення списку orphan pages потрібно знайти релевантні сторінки, з яких логічно поставити посилання. Наприклад, якщо orphan — стаття про «Налаштування мета-тегів», додаємо посилання на неї з розділу «SEO-оптимізація» та із сусідніх статей за темою. Використовуйте систему тегів або TF-IDF для пошуку схожих матеріалів. Економія бюджету на SEO може сягати 30% — при сайті з 1000 сторінок це становить економію близько 36000 грн на рік.

Частота аудиту внутрішньої перелінковки

Рекомендуємо проводити аудит після кожного масштабного оновлення контенту або не рідше одного разу на півроку. Регулярна перевірка дозволяє своєчасно виявляти нові orphan pages та коригувати розподіл ваги. Згідно з нашим досвідом, 90% сайтів мають помилки внутрішньої перелінковки.

Що входить у послугу оптимізації внутрішньої перелінковки

Ми проводимо повноцінний SEO аудит внутрішньої перелінковки: виявляємо orphan pages, аналізуємо розподіл PageRank, перевіряємо anchor text на монотонність, оцінюємо глибину вкладеності. Потім розробляємо нову структуру з плоскою ієрархією та тематичними кластерами. Результат — документація з рекомендаціями, чек-лист для впровадження та консультація. Наша компанія має 5 років досвіду на ринку SEO і виконала більше 150 проєктів. Вартість аудиту сайту до 100 сторінок стартує від 5000 грн, від 100 до 1000 сторінок — від 12000 грн. Термін виконання: від 2 до 5 робочих днів. Економія бюджету на SEO може сягати 30%, що при сайті з 1000 сторінок становить економію близько 36000 грн на рік. Ми гарантуємо підвищення індексації та покращення Core Web Vitals.

Замовте SEO аудит перелінковки сайту вже сьогодні — наші інженери підготують індивідуальне рішення. Зв'яжіться з нами для отримання консультації та безкоштовного чек-листа.

Покроковий план дій:

  1. Проведіть краулінг сайту та побудуйте граф переходів.
  2. Виявіть orphan pages та сторінки з глибокою вкладеністю.
  3. Розподіліть PageRank шляхом додавання внутрішніх посилань на важливі сторінки.
  4. Організуйте тематичні кластери для групування пов'язаного контенту.
  5. Автоматизуйте хлібні крихти та оптимізуйте anchor text.

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