Przykładowy dokument

Rejestr problemów technicznych: znaleziska zamienione w zadania dla programisty

Każdy wiersz tego rejestru jest napisany tak, żeby programista, który nie czytał audytu, mógł go wziąć, odtworzyć problem, naprawić go i wykazać, że zadanie jest zamknięte. To różnica między raportem a pracą, która naprawdę wchodzi na produkcję.

Przykład, a nie dane klienta

Sytuacja jest wymyślona: serwis mocno treściowy na popularnym systemie zarządzania treścią, niedawno przeniesiony na nową platformę, jedno wspólne środowisko testowe i zespół, który wdraża raz w tygodniu. Wszystkie adresy prowadzą do example.com. Nie ma tu prawdziwego klienta ani prawdziwego backlogu.

Jak zbudowany jest wiersz

Zadanie, z którym da się polemizować, to zadanie, które zostaje zrobione. Każda kolumna usuwa jeden z powodów, dla których praca grzęźnie między audytem a wdrożeniem.

ID: stała etykieta, dzięki której ten sam problem zachowuje nazwę w backlogu, w notatce wdrożeniowej i w kontrolnym crawlu po wszystkim.
Waga: krytyczna blokuje crawl, renderowanie albo indeksowanie. Wysoka pogarsza sposób czytania strony. Średnia to higiena, która może poczekać na planowe wdrożenie.
Dowód: najkrótsza droga do zobaczenia problemu na własne oczy, napisana dla kogoś bez kontekstu audytu.
Kryterium odbioru: stan obserwowalny, a nie zamiar. Albo kryterium jest spełnione na żywej stronie, albo zadanie zostaje otwarte.
Właściciel: kto to wdraża. Część wierszy robimy sami na ograniczonym dostępie, część należy do zespołu programistów, a część wymaga obu stron.

Rejestr

ID	Problem	Waga	Dowód	Kryterium odbioru	Właściciel
T-01	Dyrektywa blokująca crawl ze środowiska testowego działa na hoście publicznym	Krytyczna	Otwórz plik robots na example.com i poszukaj reguły, która blokuje całą witrynę	Żywy plik robots dopuszcza sekcje publiczne, a reguła blokująca istnieje tylko na środowisku testowym	My, hosting potwierdza
T-02	Treść w szablonie usługi pojawia się dopiero po hydracji	Krytyczna	Pobierz stronę z wyłączonym JavaScriptem i poszukaj pierwszego akapitu w surowej odpowiedzi	Pierwszy akapit jest obecny w surowym kodzie HTML na każdej stronie usługi	Programista klienta, my specyfikujemy
T-03	Znacznik noindex wraca na stronę główną bloga po niektórych wdrożeniach	Krytyczna	Porównaj sekcję head strony głównej bloga z dwóch ostatnich wdrożeń	Dwa kolejne wdrożenia przechodzą bez tego znacznika, a reguła wykrywania zmian go pilnuje	My z programistą klienta
T-04	Strony stronicowane w kategorii mają canonical na pierwszą stronę	Wysoka	Otwórz drugą stronę dowolnej kategorii i przeczytaj element canonical	Każda strona stronicowana ma canonical na samą siebie, a linki stronicowania zostają dostępne dla robota	Programista klienta, my specyfikujemy
T-05	Stare adresy produktów docierają do celu przez dwa przekierowania	Wysoka	Wywołaj stary adres produktu i przejdź łańcuch do końca	Każdy stary adres dociera do celu jednym stałym przekierowaniem	My
T-06	Jednemu językowi brakuje odnośników zwrotnych w zestawie hreflang	Wysoka	Porównaj blok hreflang na parze stron w obu językach	Każda para językowa wskazuje na drugą stronę i na siebie, a zestaw przechodzi walidację	My
T-07	Usunięta strona odpowiada normalnym statusem i ostylowanym szablonem	Wysoka	Wywołaj adres skasowanego produktu i odczytaj kod odpowiedzi	Usunięte adresy odpowiadają statusem nie znaleziono albo usunięto, a szablon nie jest indeksowalny	Programista klienta
T-08	Parametry filtrów tworzą adresy dostępne dla robota, których nikt nie szuka	Wysoka	Przeskanuj jedną kategorię i wypisz warianty parametrów osiągalne z linków	Dla robota i indeksu zostają tylko kombinacje wskazane w uzgodnionej polityce parametrów	My z programistą klienta
T-09	Dane strukturalne okruszków wstrzykiwane są po załadowaniu strony	Średnia	Poszukaj typu okruszków w surowej odpowiedzi strony produktu	Dane strukturalne są w surowym kodzie HTML i przechodzą walidację bez ostrzeżeń	Programista klienta, my specyfikujemy
T-10	Mapa witryny wymienia adresy, które przekierowują albo są wyłączone z indeksu	Średnia	Weź próbkę adresów z mapy witryny i sprawdź status każdego z nich	Mapa powstaje z żywego zbioru stron indeksowalnych i odświeża się przy publikacji	Programista klienta, my specyfikujemy
T-11	Zapytania robota skupiają się na adresach z parametrami zamiast na kategoriach	Średnia	Przeczytaj tydzień logów serwera i pogrupuj zapytania według wzorca adresu	Polityka parametrów działa, a to samo okno logów czytamy ponownie, żeby zobaczyć, jak przesunął się rozkład	My

Kolejność prac

O kolejności decyduje to, co odblokowuje resztę, a nie to, jak szybko da się zamknąć wiersz. Szybka poprawka zależna od nienaprawionego blokera marnuje się dwa razy.

Najpierw wszystko, co uniemożliwia zeskanowanie, wyrenderowanie albo poprawne zwrócenie strony. Dopóki to jest otwarte, niczego innego nie da się zmierzyć.
Potem reguły decydujące o tym, co należy do indeksu: canonical, stronicowanie, parametry, kody odpowiedzi.
Dalej dane strukturalne i szczegóły dostarczania, które zmieniają sposób podania strony już poprawnie odczytanej.
Na końcu monitoring, który pilnuje, żeby trzy pierwsze grupy po cichu nie wróciły przy rutynowym wdrożeniu.

Zasady bezpiecznego wdrażania

Każda zmiana ląduje najpierw na środowisku testowym, a testowe skanujemy, zanim ktokolwiek dotknie strony produkcyjnej.
Jedna klasa zmian na wdrożenie. Reguły canonical i mapa przekierowań wypuszczone razem są nie do rozdzielenia, kiedy coś się posypie.
Każde zadanie ma ścieżkę wycofania: poprzednią regułę, plik albo szablon, trzymane tam, gdzie twój zespół przywróci je bez nas.
Zmiany wpływające na to, co jest w indeksie, klient zatwierdza pisemnie, w zadaniu, przed wdrożeniem.
Dostęp jest ograniczony do tego, czego wymaga zadanie, i odbierany po zamknięciu sprintu. Nie prosimy o uprawnienia administratora, do których nie mamy zastosowania.
Po wdrożeniu robimy kontrolny crawl i porównujemy go z tym sprzed zmian, żeby poprawka, która zepsuła coś obok, była widoczna od razu.

Co sprawdzamy po każdym wdrożeniu

Samo kryterium zadania, na żywej stronie, a nie na środowisku testowym.
Surowy kod HTML dotkniętych szablonów, bo zmiana widoczna dopiero po uruchomieniu JavaScriptu tak naprawdę nie weszła.
Kody odpowiedzi i przekierowania dla zbiorów adresów, których dotknęło wdrożenie.
Pokrycie i sygnały crawlu w Search Console przez kolejne tygodnie, bo platforma pokazuje zmianę we własnym rytmie.

Przykład syntetyczny, nie dane klienta

Rejestr jest tu krótki i uporządkowany. Prawdziwy jest dłuższy i trzyma także wiersze, które okazały się nie być problemami, z notatką dlaczego.
Wagę przypisujemy wobec konkretnej witryny. Ten sam wiersz bywa krytyczny w jednym projekcie i średni w innym.
Nic w tym przykładzie nie jest zmierzone. W prawdziwym zadaniu kolumna dowodu wskazuje pliki, adresy i okna logów.
Kolumna właściciela idzie za modelem dostępu ustalonym na starcie. Tam, gdzie wszystko wdraża twój zespół, te wartości czyta się inaczej.

Prawdziwy rejestr dostajesz jako gotowy backlog: zadania do zaimportowania przez twój zespół, specyfikację do każdego wiersza i kontrolny crawl po wdrożeniu, który zamyka każde zadanie wobec jego własnego kryterium. Zakres sprintu opisujemy na stronie usługi.

Technical SEO

Chcesz oddać konfigurację nam?

Opisz, co masz dziś. Zakres i stałą cenę potwierdzamy przed rozpoczęciem prac, a wszystkie dostępy zostają u Ciebie.

Zacznij konfigurację

Bez zobowiązań. Odpowiedź w ciągu jednego dnia roboczego.