Зразок документа
Реєстр технічних проблем: знахідки стають задачами, які розробник закриє
Кожен рядок реєстру написаний так, щоб розробник, який не читав аудиту, міг узяти його, відтворити проблему, виправити і довести, що вона закрита. Саме це відрізняє звіт від роботи, яка справді доїжджає до релізу.
Приклад, а не дані клієнта
Обстановка вигадана: контентний сайт на поширеній системі керування вмістом, нещодавно переїхав на нову платформу, одне спільне середовище staging і команда розробки, яка релізить раз на тиждень. Усі URL вказують на example.com. Реального клієнта і реального беклогу тут немає.
Як побудований рядок
Задача, з якою можна сперечатися, це задача, яку роблять. Кожна колонка існує, щоб зняти одну з причин, через які робота гальмується між аудитом і релізом.
- ID: стала мітка, щоб та сама проблема тримала свою назву в беклозі, у нотатках релізу і в подальшому QA скануванні.
- Критичність: критично блокує сканування, рендеринг або індексацію. Високий погіршує те, як читають сторінку. Середній це гігієна, яка може почекати планового релізу.
- Доказ: найкоротший шлях побачити проблему самому, написаний для того, хто не має контексту аудиту.
- Критерій приймання: спостережуваний стан, а не намір. Або критерій виконано на живому сайті, або задача лишається відкритою.
- Власник: хто це релізить. Частину рядків робимо ми з обмеженим доступом, частина належить команді розробки, а частина потребує обох.
Реєстр
| ID | Проблема | Критичність | Доказ | Критерій приймання | Власник |
|---|---|---|---|---|---|
| T-01 | Директива staging, що блокує сканування, живе на публічному хості | Критично | Відкрити файл robots на example.com і знайти правило, яке забороняє весь сайт | Живий файл robots дозволяє публічні розділи, а блокуюче правило лишається тільки на staging | Ми, хостинг підтверджує |
| T-02 | Текст на шаблоні послуги виникає лише після гідратації | Критично | Запросити сторінку з вимкненим JavaScript і пошукати в сирій відповіді перший абзац | Перший абзац присутній у сирій HTML відповіді на кожній сторінці послуги | Розробник клієнта, ми пишемо специфікацію |
| T-03 | Тег noindex повертається на головну блогу після частини релізів | Критично | Порівняти head головної блогу за два останні деплої | Два релізи поспіль проходять без тега, і за ним стежить правило виявлення змін | Ми з розробником клієнта |
| T-04 | Сторінки пагінації категорій канонікалізуються на першу | Високий | Відкрити другу сторінку будь-якої категорії і прочитати елемент canonical | Кожна сторінка пагінації канонікалізується сама на себе, а посилання пагінації лишаються доступними для сканера | Розробник клієнта, ми пишемо специфікацію |
| T-05 | Старі URL товарів доходять до призначення через два переходи редиректу | Високий | Запросити старий URL товару і пройти ланцюг до кінця | Кожен старий URL доходить до призначення одним постійним редиректом | Ми |
| T-06 | В однієї мови немає зворотних посилань у наборі hreflang | Високий | Порівняти блок hreflang на парі сторінок обома мовами | Кожна мовна пара посилається одна на одну і на себе, а набір проходить валідацію | Ми |
| T-07 | Видалена сторінка відповідає звичайним статусом і оформленим шаблоном | Високий | Запросити URL видаленого товару і прочитати код статусу | Видалені URL відповідають статусом not found або gone, а шаблон не індексується | Розробник клієнта |
| T-08 | Параметри фільтрів створюють доступні для сканера URL, яких ніхто не шукає | Високий | Просканувати одну категорію і виписати варіанти параметрів, доступні з посилань | Для сканування і індексації лишаються тільки комбінації з узгодженої політики параметрів | Ми з розробником клієнта |
| T-09 | Розмітка хлібних крихт вставляється після завантаження сторінки | Середній | Пошукати тип хлібних крихт у сирій відповіді сторінки товару | Розмітка присутня в сирому HTML і проходить валідацію без попереджень | Розробник клієнта, ми пишемо специфікацію |
| T-10 | Карта сайту містить URL, що перенаправляють або виключені з індексації | Середній | Взяти вибірку URL з карти сайту і перевірити статус кожного | Карта генерується з живого набору індексованих сторінок і перегенеровується під час публікації | Розробник клієнта, ми пишемо специфікацію |
| T-11 | Запити сканера зосереджені на URL з параметрами, а не на сторінках категорій | Середній | Прочитати логи доступу за тиждень і згрупувати запити за шаблоном URL | Політика параметрів працює, і те саме вікно логів читають ще раз, щоб побачити, як змістився розподіл | Ми |
Порядок робіт
Порядок визначає те, що розблоковує решту, а не швидкість закриття рядка. Швидке виправлення, яке залежить від невиправленого блокера, витрачене двічі.
- Спочатку все, що не дає сторінці бути просканованою, відрендереною або повернутою правильно. Поки це відкрито, решту не виміряти.
- Далі правила, які вирішують, що потрапляє в індекс: канонічні, пагінація, параметри, коди статусу.
- Потім розмітка і деталі віддачі, які змінюють подачу сторінки, коли її вже читають правильно.
- Наприкінці моніторинг, який не дає першим трьом тихо повернутися на черговому релізі.
Правила безпечного впровадження
- Кожна зміна спершу виїжджає на staging, і staging сканують до того, як хтось торкнеться живого сайту.
- Один клас змін на реліз. Правило канонічних і карту редиректів, які виїхали разом, неможливо розділити, коли щось попливло.
- Кожна задача має відкат: попереднє правило, файл або шаблон, збережені там, звідки ваша команда відновить їх без нас.
- Зміни, що впливають на склад індексу, клієнт підтверджує письмово, у самій задачі, до релізу.
- Доступ обмежений тим, що потрібно задачі, і відкликається після закриття спринту. Ми не просимо прав адміністратора, які нам ні до чого.
- Після релізу ми робимо QA сканування і порівнюємо його з тим, що зняли до, щоб виправлення, яке зламало сусіднє, було видно одразу.
Що перевіряємо після кожного релізу
- Сам критерій задачі, на живому сайті, а не на staging.
- Сирий HTML зачеплених шаблонів, бо зміна, яка виникає лише після JavaScript, насправді не виїхала.
- Коди статусу і редиректи для наборів URL, яких торкнувся реліз.
- Покриття і сигнали сканування в Search Console протягом наступних тижнів, бо платформа відображає зміну за власним розкладом.
Вигаданий приклад, не дані клієнта
- Реєстр тут короткий і охайний. Справжній довший і зберігає також рядки, які виявилися не проблемою, з поясненням чому.
- Критичність призначають щодо того сайту, якому рядок належить. Той самий рядок буває критичним на одному проєкті і середнім на іншому.
- У цьому зразку нічого не виміряно. У справжній задачі колонка доказу називає файли, URL і вікна логів.
- Колонка власника йде за моделлю доступу, узгодженою на старті. Там, де ваша команда релізить усе, ці значення читаються інакше.
Справжній реєстр передають як робочий беклог: задачі, які ваша команда імпортує, специфікацію на кожен рядок і сканування після релізу, що закриває кожну задачу за її власним критерієм. Обсяг спринту описаний на сторінці послуги.
Technical SEOГотові віддати налаштування нам?
Розкажіть, що у вас є зараз. Обсяг і фіксовану ціну підтверджуємо до початку робіт, усі доступи лишаються у вас.
Почати налаштуванняБез зобов'язань. Відповідь протягом одного робочого дня.