Zacznij od strony i obsługiwanej funkcji
Nie zaczynaj od dodawania każdego typu schema.org, który brzmi powiązanie z Twoją działalnością. Schema.org to szerokie wspólne słownictwo, podczas gdy dokumentacja Google (Search Gallery) opisuje funkcje wyników rozszerzonych, które obsługuje, oraz właściwości, których wymagają. Strona produktu, wydarzenia lub artykułu powinna najpierw być użyteczna bez znaczników.
Dla każdego szablonu nazwij jego główny podmiot i widoczne wspierające fakty. Potem przeczytaj aktualny przewodnik Google dla odpowiadającej funkcji. Przykłady to Product, Recipe, Article, Breadcrumb, Event, Organization, Local business i Video. Sam typ z vocabularium nie tworzy funkcji Google; to wymagane właściwości tej funkcji określają uprawnienia.
Uczyń główny widoczny element głównym obiektem znaczników.
Korzystaj z przewodnika Google dla zachowań funkcji i z schema.org dla słownictwa.
Niech widoczna strona będzie źródłem prawdy
Znaczniki muszą odzwierciedlać główną treść strony, a nie ukryte, nieistotne lub mylące materiały. Jeśli mówią, że występuje wykonawca, strona musi go opisywać. Jeśli oznaczają ocenę zbiorczą, odwiedzający muszą widzieć tę ocenę. To zapobiega temu, by szablon dryfował w stronę wprowadzającego w błąd podsumowania.
Buduj treść strony i znaczniki z tych samych zatwierdzonych rekordów. Feed produktowy, system wydarzeń lub CMS może dostarczać obydwa, ale wartości wymagają przeglądu przed publikacją. Nie kopiuj ceny, stanu magazynowego, daty ani liczby recenzji wyłącznie do pola tylko w znacznikach, które mogą zostać zapomniane. Aktualizuj lub usuwaj znaczniki, gdy widoczna informacja się zmienia.
Utrzymuj nazwy, daty, ceny, dostępność i oceny zgodne ze stroną.
Nigdy nie wypełniaj właściwości zgadywanymi lub przestarzałymi wartościami.
Używaj JSON-LD jako warstwy danych łatwej w utrzymaniu
JSON-LD to oparte na JSON formatowanie danych połączonych umieszczane w dokumencie HTML. Google obsługuje JSON-LD, Microdata i RDFa, i wskazuje, że JSON-LD jest zwykle najłatwiejszy do wdrożenia i utrzymania w skali. Jego separacja od widocznego markupu może ułatwić modelowanie zagnieżdżonych informacji.
Użyj jednego klarownego obiektu danych dla każdego rzeczywistego elementu, z odpowiednim typem schema.org i dokładnymi obsługiwanymi właściwościami. Dla każdego szablonu udokumentuj przewodnik funkcji, pole źródłowe, zachowanie wymaganych pól i właściciela. Sprawdź także wyrenderowane wyjście: wtyczka lub komponent może dodawać zduplikowane lub konfliktujące znaczniki.
Wybierz format, który Twój zespół potrafi utrzymywać konsekwentnie.
Nie wymyślaj wymaganej wartości, gdy brak jej w źródle.
Zwaliduj kod i dostępność strony
Walidacja odpowiada na dwa pytania. Po pierwsze, czy znaczniki są wystarczająco kompletne dla obsługiwanej funkcji? Narzędzie Rich Results Test akceptuje wklejony kod lub publiczny URL i informuje, jakie wyniki rozszerzone można wygenerować z danych strukturalnych. Testuj reprezentatywne przykłady dla każdego szablonu, a nie jedną wyjątkowo kompletną stronę.
Po drugie, czy Google ma dostęp do wydanej strony i zasobów? Nie blokuj oznaczonych stron przez robots.txt, noindex ani kontrolę dostępu. Sprawdź istotne URL obrazów. Test nie jest gwarancją jakości: problemy z widoczną treścią lub zgodnością z zasadami nadal mogą uniemożliwić wyświetlenie.
Najpierw przetestuj kod, potem przetestuj działający publiczny URL.
Porównaj wyrenderowaną stronę, źródło i wynik testu, gdy narzędzia dodają znaczniki.
Potencjalne wyświetlenie nie jest obietnicą ostatecznego pokazania.
Wydawaj to jak zmianę widoczną dla użytkownika
Dane strukturalne często zależą od szablonów, feedów i reguł publikacji. Redesign, zmiana integracji zapasów, aktualizacja lokalizacji lub usunięty komponent może zepsuć wiele elementów. Dodaj reprezentatywne kontrole znaczników do przeglądu przed wydaniem używanego dla tagów kanonicznych, tytułów i obrazów. Zapisz szablon, przykładowe strony, pola źródłowe i datę wydania.
Gdy szablon emituje błędne znaczniki, popraw wspólne źródło lub szablon, zwaliduj małą próbkę, wdroż najwęższą bezpieczną zmianę i ponownie przetestuj dotknięte URL-e. Jeśli poprawka zachowuje się nieoczekiwanie, użyj normalnego procesu rollback. Celem jest oparte na dowodach przywrócenie zdegradowanej możliwości sieciowej, a nie alert o awarii.
Sprawdzaj reprezentatywne zestawy stron, nie pojedynczy URL.
Zapisz zmianę i komponent znaczników przed kolejną poprawką.
Utrzymuj, mierz i akceptuj limit wyświetlania
Po wdrożeniu korzystaj z odpowiedniego raportu o wynikach rozszerzonych w Search Console, aby badać problemy i potwierdzać naprawy. Raporty są próbkami, a nie pełną inwentaryzacją, a liczby odnoszą się do elementów, nie stron. W razie potrzeby zbadania sprawdź konkretny URL.
Mierz ostrożnie. Google sugeruje porównanie przed i po na stabilnych, wystarczająco czytanych stronach przez miesiące w Search Console. Zapisz datę wydania i inne zmiany strony. Poprawne znaczniki umożliwiają jedynie uprawnienia; ostateczne przedstawienie w wynikach wybiera Google.
Ponownie sprawdzaj po zmianach CMS, szablonu, feedu, polityki lub modelu treści.
Unikaj porównań, w których inne zasadnicze zmiany strony się różnią.