Якщо ви тільки починаєте займатися SEO, сприймайте PageRank як корисну ідею про те, як посилання з'єднують сторінки, а не як число, яке можна знайти й підвищити. Google не показує актуальну оцінку PageRank для ваших сторінок. Натомість ви можете полегшити людям і пошуковим системам пошук важливих сторінок, виправити явно зламані шляхи та спрямувати старі URL на справді релевантні заміни.
Цей посібник показує практичний спосіб зробити це за допомогою Codex. Він не обіцяє позицій, не вигадує метрики посилань і не вносить зміни на ваш сайт у продакшені. Він перетворює дані, які ви маєте право використовувати, на короткий список завдань, готовий до перевірки.
Codex готує робочий список, підкріплений доказами. Людина й надалі відповідає за схвалення та перевірку кожної зміни на сайті.
Що ви матимете наприкінці
Це робочий процес для власника сайту, маркетолога або SEO-початківця, який має доступ до вивантаження сканування, внутрішніх посилань, списку редиректів або невеликого вивантаження Search Console.
Наприкінці ви матимете:
- список перевірених кандидатів на виправлення зламаних внутрішніх посилань;
- кандидатів на редирект, для яких людина має підтвердити сторінку-заміну;
- ідеї контекстних внутрішніх посилань на важливі для вас сторінки; і
- CSV, що фіксує докази, рівень упевненості та перевірку людиною для кожної запропонованої зміни.
Щоб зрозуміти процес, вам не потрібна підписка на SEO-інструмент. Але потрібен дозвіл на використання даних і хтось, хто перегляне зміни до їх потрапляння на сайт.
PageRank коротко
PageRank починався як спосіб використовувати посилання в інтернеті як доказ під час упорядкування сторінок. Початкова ідея була елегантною: посилання могло бути сигналом, що інша сторінка варта розгляду. Але це ніколи не був простий публічний лічильник голосів і це не сучасна панель ранжування.
Сучасний Пошук Google використовує багато сигналів і систем. Google також пояснює, що зазвичай знаходить нові сторінки через посилання та карти сайту, а його документація рекомендує доступні для сканування посилання <a>, коли ви хочете, щоб Google знайшов іншу сторінку. Тому внутрішні посилання залишаються корисними для навігації та виявлення сторінок, навіть якщо немає видимого балу PageRank, за яким можна гнатися.
Практичне питання не таке: «Як збільшити PageRank?». Краще запитайте:
Чи може відвідувач і сканер дістатися цієї важливої сторінки чітким, релевантним шляхом?
Це питання веде до роботи, яку можна перевірити й покращити.
На що PageRank не дає вам дозволу
Саме міфи про PageRank часто збивають SEO-початківців зі шляху.
Спокусливий обхідний шлях | Корисніше правило |
|---|---|
Купити посилання, бо високою виглядає оцінка стороннього сервісу | Оцініть, чи посилання редакційно релевантне, корисне читачеві та отримане відповідно до правил Google щодо спаму. |
Додати посилання на сторінку продажу всюди | Додавайте посилання лише там, де воно допомагає читачеві продовжити свою дію. |
Переспрямувати кожен старий URL на головну сторінку | Робіть редирект лише коли стара й нова сторінки близько та чесно відповідають одна одній; інакше спершу перевірте призначення URL. |
Вважати метрику SEO-інструмента PageRank від Google | Вважайте її оцінкою цього інструмента. Вона може допомогти пріоритезувати роботу, але це не приватний розрахунок Google. |
Попросити ШІ-агента «виправити всі посилання» | Попросіть знайти кандидатів, підтверджених доказами, а зміни нехай схвалить людина. |
Ця обережність важлива, бо поганий редирект може привести людей до неправильного вмісту, а нав'язане внутрішнє посилання може погіршити посібник. Посилання є хорошим SEO, коли воно також покращує шлях користувача сайтом.
Шляхи сторінок, які варто перевірити першими
Не починайте з кожного URL великого сайту. Почніть із невеликого набору сторінок, де зрозуміліший шлях дає читачеві очевидну користь.
1. Посилання, що ведуть на сторінку помилки
Якщо поточна сторінка посилається на наданий URL 4xx, відвідувач потрапляє в глухий кут. Зазвичай це найочевидніше перше виправлення. Перевірте, чи має початкове призначення актуальний еквівалент. Якщо так, оновіть вихідне посилання. Якщо ні, приберіть або замініть його наступним ресурсом, який справді допомагає.
2. Зняті з використання сторінки, що мають реального наступника
Старі сторінки товарів, перенесені посібники та змінена структура URL часто залишають по собі посилання. Редирект може бути доречним, якщо нове призначення переважно задовольняє ту саму потребу. Сторінка про скасований тарифний план не повинна автоматично перенаправляти на головну лише тому, що обидві сторінки на одному домені.
Редирект - це рішення про призначення. Це не автоматична відповідь на кожен знятий з використання URL.
3. Важливі сторінки, до яких важко дістатися
Важливий посібник може технічно бути в індексі, але отримувати дуже мало внутрішніх посилань. Якщо пов'язана стаття вже відповідає на попередній крок у шляху читача, звичайне контекстне посилання може спростити пошук цієї сторінки. Шукайте тематичну відповідність до підрахунку посилань.
4. Навігація, що приховує справжнє призначення
Рекомендації Google щодо посилань наголошують на звичайних посиланнях, доступних для сканування. Якщо до ключової сторінки можна дістатися лише через ненадійну взаємодію зі скриптом, надсилання форми або поле пошуку, попросіть розробника перевірити шлях. Це не причина перебудовувати сайт з нуля. Це причина зробити важливі призначення доступними через звичайні посилання там, де це доречно.
Перш ніж просити Codex про допомогу
Codex може організувати аудит. Без вхідних даних він не знає стан вашого сайту й не повинен вгадувати.
Надайте найменший корисний набір вивантажень, яким ви маєте право ділитися:
Вхідні дані | Корисні стовпці | Що це може підтримати |
|---|---|---|
Вивантаження сканування | URL, код стану, canonical, можливість індексації, вхідні посилання, вихідні посилання, заголовок | Зламані сторінки, конфлікти canonical, перевірку сторінок із малою кількістю посилань |
Вивантаження внутрішніх посилань | URL джерела, URL призначення, текст якоря, тип посилання | Зламані внутрішні посилання та перевірку контекстних посилань |
Вивантаження редиректів або старих URL | Старий URL, фінальний URL, стан, згадки | Кандидатів на редирект і перевірку ланцюгів редиректів |
Вивантаження сторінок Search Console | Сторінка, кліки, покази, CTR, позиція, діапазон дат | Розмову про бізнес-пріоритет, а не обчислення PageRank |
Ваш короткий список пріоритетів | URL, мета сторінки, пріоритет | Спосіб зосередити аудит на важливих сторінках |
Перед поширенням видаліть чутливі пошукові запити, дані клієнтів і облікові дані. Вкажіть діапазон дат і охоплення кожного вивантаження. Часткове сканування може дати лише часткову відповідь.
Використовуйте Codex як аудитора, а не як автопілот
Найбезпечніша роль Codex - підготувати робочий список. Дотримуйтеся такої послідовності.
Крок 1: помістіть копії вивантажень в одну папку
Створіть робочу папку, наприклад site-link-audit/. Залиште оригінали без змін. Розмістіть там лише авторизовані вивантаження CSV або XLSX і, якщо маєте, короткий файл priorities.csv.
Очікуваний результат: Codex може прочитати назви файлів і заголовки без доступу до приватних входів або ключів API.
Перевірка якості: відкрийте кожен файл і підтвердьте, що охоплення та дата вивантаження мають сенс. Якщо сканування обмежувалося однією підпапкою, зазначте це.
Якщо у вас немає вивантажень: створіть простий ручний інвентар із url, page_title, content_type, priority, known_replacement_url і notes. Він підтримує лише планування. Він не може довести, що посилання зламане або що сторінці бракує внутрішніх посилань.
Крок 2: запустіть Skill аудиту
Збережіть наведене нижче як SKILL.md у локальній або репозиторній папці Skill відповідно до звичайного налаштування Codex вашої команди, а потім попросіть Codex перевірити папку. Посібник OpenAI Build skills описує локальні та репозиторні розташування, які Codex може сканувати. Якщо ви не використовуєте Skills, коротший prompt у наступному розділі дає ті самі операційні правила для одного сеансу.
---
name: codex-link-equity-audit
description: Аудитуйте авторизовані вивантаження сканування, внутрішніх посилань, редиректів і Search Console, щоб знайти можливості link equity, готові до перевірки. Використовуйте, коли SEO-початківцю потрібно знайти зламані внутрішні посилання, важливі сторінки з малою кількістю посилань, кандидатів на редирект або безпечний план внутрішніх посилань із наданих даних CSV чи XLSX.
---
# Аудит link equity за допомогою Codex
Створіть обережний SEO-робочий список, який може перевірити людина, на основі даних, які користувач має право надати. Це процес аудиту й планування, а не автоматичний процес редагування сайту.
## Межі безпеки
- Використовуйте лише файли, URL і джерела даних, які користувач явно надає або авторизує.
- Ніколи не запитуйте, не друкуйте, не зберігайте й не розкривайте ключі API, файли cookie, паролі або токени.
- Ніколи не вигадуйте Google PageRank, позиції, беклінки, трафік, обсяг пошуку, результати сканування або метрики інструментів.
- Не входьте в акаунти, не викликайте платні API, не змінюйте сайт, не публікуйте редиректи, не додавайте посилання й не надсилайте URL, якщо користувач окремо не авторизував саме цю дію.
- Позначайте кожну рекомендацію як запропоновану, доки людина не перевірить релевантність, canonical-ціль, цінність для користувача та впровадження.
## Спочатку перевірте вхідні дані
Прочитайте надані назви файлів і фактичні заголовки. Не припускайте, що crawler, SEO-інструмент, CMS або вивантаження Search Console використовує стандартну схему. Вкажіть, що може підтримати кожен файл і чого бракує.
Попросіть найменший корисний набір: вивантаження сканування, вивантаження внутрішніх посилань, вивантаження редиректів або зламаних URL, вивантаження сторінок Search Console із зазначеним діапазоном дат і список пріоритетних сторінок. Якщо нічого з цього немає, попросіть ручний інвентар URL і поясніть, що він підтримує лише планування.
## Створюйте кандидатів, підкріплених доказами
1. Зберігайте сирі URL і нормалізуйте їх лише для порівняння. Позначайте відмінності протоколу, хоста, кінцевого слеша, параметрів, фрагментів, редиректів і canonical замість тихого об'єднання.
2. Записуйте охоплення, діапазон дат, кількість рядків, релевантні стовпці та прогалини даних.
3. Пропонуйте лише такі дії, коли надані докази їх підтримують:
- `fix_internal_link` для наданої сторінки-джерела, яка посилається на надану ціль 4xx;
- `review_redirect` для знятого з використання URL із наданими доказами згадок і справді еквівалентною активною ціллю;
- `suggest_internal_link`, коли надані джерело та пріоритетна ціль мають чітку тематичну відповідність, корисну читачеві;
- `investigate_underlinked_page` лише коли є порівнювані кількості внутрішніх посилань або дані графа;
- `investigate_canonical_or_redirect` лише коли надані поля встановлюють конфлікт.
4. Призначайте пріоритет `high`, `medium` або `low` за бізнес-важливістю, доказами зламаного шляху, наданою кількістю згадок і тематичною відповідністю. Не називайте жоден пріоритет балом PageRank і не прогнозуйте зміну позицій.
## Запишіть результати
Створіть `link-equity-audit.md` і `link-equity-actions.csv` у вибраній користувачем вихідній папці. Зберігайте всі вхідні дані.
Використовуйте такі стовпці CSV:
```csv
action_id,action_type,source_url,proposed_destination_url,anchor_or_change,evidence,evidence_source,confidence,implementation_priority,human_review_check,evidence_gap,status
```
Використовуйте `proposed` як початковий стан. Markdown-звіт має містити заяву про охоплення й дозвіл, пояснення простою мовою, обмеження, завдання для негайного виправлення, завдання для подальшої перевірки, питання, що потребують більше даних, і контрольний список упровадження з нотатками про відкат.
## Поріг якості
Видаляйте рекомендацію без доказів, із ціллю, яка лише схожа, але не є реальною заміною, із внутрішнім посиланням, що не допомагає читачеві, або зі зміною редиректу/canonical, яка може вплинути на інший URL без людської перевірки. Завершуйте переліком використаних входів, обмежень, створених файлів і наступного кроку перевірки.Очікуваний результат: два нові файли, link-equity-audit.md і link-equity-actions.csv. Кожен рядок пояснює, чому він існує та що має перевірити людина.
Перевірка якості: перегляньте CSV. Хороший рядок має джерело доказу, конкретну запропоновану зміну, рівень упевненості та людську перевірку. Видаліть рядки, які лише кажуть «покращити SEO» або пропонують ціль без пояснення.
Крок 3: перегляньте робочий список у такому порядку
Почніть із перевірених зламаних внутрішніх посилань. Зазвичай їх легко зрозуміти й за потреби скасувати.
Далі перегляньте кандидатів на редирект. Запитайте: «Чи вважатиме людина, яка хотіла стару сторінку, нову сторінку чесним наступним призначенням?» Якщо відповідь неясна, не публікуйте редирект лише для збереження сигналу.
Насамкінець перегляньте запропоновані контекстні посилання. Прочитайте речення навколо запропонованого джерела. Текст якоря повинен природно описувати призначення, а пов'язана сторінка має справді допомагати в цей момент.
Очікуваний результат: невеликий набір схвалених змін, а не великий список механічних змін.
Перевірка якості: кожна схвалена дія має названого відповідального та план відкату. Для нового внутрішнього посилання відкат означає видалення, якщо воно погіршує текст. Для редиректу це означає відновлення попередньої поведінки, якщо моніторинг показує неправильне зіставлення.
Крок 4: упровадьте та перевірте
Вносіть зміни через звичайний процес CMS, code review або деплою. Не просіть ШІ-агента тихо редагувати сторінки в продакшені.
Після релізу протестуйте змінені вихідні URL у браузері. Для редиректів відкрийте старий URL і підтвердьте фінальне призначення, HTTP-поведінку та релевантність сторінки. Для внутрішніх посилань підтвердьте, що якір працює, призначення завантажується, а текст навколо зберігає природність.
Документація Google про редиректи і найкращі практики посилань є хорошою довідкою, коли впровадження стає технічним.
Prompt для одного сеансу, якщо ви не встановлюєте Skill
Помістіть авторизовані вивантаження в поточну робочу папку та використайте цей prompt:
Дій як обережний помічник з SEO-аудиту. Спочатку перевір надані реальні назви файлів і заголовки. Використовуй лише ці авторизовані локальні дані. Не запитуй і не друкуй облікові дані, не викликай платні API, не переглядай приватні системи, не змінюй файли за межами вихідної папки й не стверджуй, що знаєш Google PageRank, позиції, трафік, беклінки або результати сканування, яких немає у вхідних даних.
Поясни охоплення даних, дати, кількість рядків, відсутні поля та те, що може підтримати кожен файл. Потім створи готові до людської перевірки `link-equity-audit.md` і `link-equity-actions.csv` у `./output/`.
Пропонуй лише дії, підкріплені доказами: виправити надане внутрішнє посилання на наданий URL 4xx; перевірити редирект, коли наданий знятий з використання URL має докази згадок і справді еквівалентну активну ціль; запропонувати контекстне посилання, коли надані сторінки мають чітку тематичну відповідність; дослідити пріоритетну сторінку з незвично малою кількістю наданих внутрішніх посилань; або дослідити доведений конфлікт canonical/редиректу.
Використовуй стовпці CSV: action_id,action_type,source_url,proposed_destination_url,anchor_or_change,evidence,evidence_source,confidence,implementation_priority,human_review_check,evidence_gap,status. Встанови status як `proposed`. Ніколи не прогнозуй покращення позицій. Видаляй рекомендації без доказів або такі, що можуть ввести користувачів в оману. Заверши наступним кроком людської перевірки.Як виглядає хороший результат
Цей приклад вигаданий. URL і докази створені, щоб показати форму елемента перевірки, а не заявити про результат реального сайту.
Поле | Приклад |
|---|---|
Тип дії |
|
Вихідний URL |
|
Запропоноване призначення |
|
Зміна | Замінити застаріле призначення в реченні «знайти пошукові терміни» |
Доказ | Надане вивантаження посилань показує, що джерело вказує на URL 404; вивантаження сканування показує, що запропонована ціль є активним посібником |
Людська перевірка | Підтвердити, що активний посібник досі виконує обіцянку речення |
Стан |
|
Приклад навмисно звичайний. У цьому суть: корисний аудит чітко обґрунтовує невелику зміну; він не створює загадковий бал і не обіцяє першу сторінку.
Як виміряти, чи допоміг робочий процес
Не оцінюйте проєкт числом PageRank. Відстежуйте речі, які ви справді змінили й можете перевірити:
- кількість схвалених і виправлених зламаних внутрішніх посилань;
- кількість знятих з використання URL, зіставлених із перевіреною еквівалентною сторінкою;
- кількість пріоритетних сторінок із новим контекстним внутрішнім шляхом, корисним читачеві; і
- чи працюють змінені URL як задумано після публікації.
Якщо ви також використовуєте Search Console, порівнюйте його звіти за розумний період і позначайте дати істотних змін. Пошукові дані можуть коливатися, і різниця після редагування не доводить, що саме редагування її спричинило. Ведіть журнал змін, щоб навчатися, а не вгадувати.
Поширені запитання
Чи можу я побачити свій Google PageRank у 2026 році?
Ні. Власники сайтів не мають доступного публічного балу PageRank. Сторонні метрики авторитетності або URL можуть допомагати пріоритезувати дослідження, але це не внутрішній бал Google і їх не слід так представляти.
Чи підвищить додавання внутрішніх посилань позицію сторінки?
Це може спростити виявлення та доступ до важливої сторінки, але жодна одна зміна не гарантує результату ранжування. Додавайте посилання, коли вони покращують шлях читача та підтримані контекстом сторінки.
Чи варто робити редирект для кожного URL 404?
Ні. Переспрямовуйте знятий з використання URL лише коли маєте близьку заміну, що задовольняє той самий намір. Неясні випадки перевіряйте окремо. Загальний редирект може створити поганий досвід для відвідувачів.
Чи може Codex автоматично використовувати Ahrefs або Search Console?
Лише якщо ви явно авторизуєте інтеграцію і її налаштовано у вашому середовищі. Ця Skill спроєктована, щоб спочатку працювати з наданими вами вивантаженнями. Вона не повинна припускати доступ або вигадувати відсутні дані.
PageRank - це те саме, що «link equity»?
Ні. «Link equity» - неформальний SEO-термін для ідеї, що посилання можуть передавати цінність або сигнали між сторінками. Це корисна мова для аудиту, але не опублікована Google метрика й не обіцянка результату.
Залиште рішення за людиною
Тривалий урок PageRank не в тому, що SEO потребує розумнішого балу. Він у тому, що веб пов'язаний. Ваше завдання - зробити ці зв'язки зрозумілими й корисними для людей. Codex може зменшити роботу з таблицями, зберегти докази та позначити прогалини. Людина все одно вирішує, чи є сторінка правильним призначенням.
Автор: Julian Mercer, практик Technical SEO в Auspia з 14-річним досвідом. Julian пише про сканованість, архітектуру сайтів і практичні основи пошуку.
