Materiał porządkuje temat: schema jest bledna albo niezgodna z trescia po migracji strony.
Po migracji strony dane strukturalne często pozostają technicznie obecne w kodzie, ale przestają odpowiadać realnej treści, nowym adresom URL, zmienionym szablonom albo logice wyświetlania podstron. Efekt jest typowy: test danych strukturalnych nie pokazuje błędów krytycznych albo pokazuje tylko ostrzeżenia, a mimo to rich results nie pojawiają się w Google. W praktyce problem nie zawsze leży w samym znaczniku Schema.org. Często źródłem jest rozjazd między tym, co widzi użytkownik, tym, co widzi Googlebot, oraz tym, co deklaruje JSON-LD.
Jeżeli schema jest błędna albo niezgodna z treścią po migracji strony, trzeba sprawdzić nie tylko poprawność składni, ale też zgodność z wytycznymi Google, indeksowalność podstron, renderowanie JavaScript, mapowanie typów danych do nowych szablonów i spójność informacji biznesowych. Poniżej znajdziesz praktyczną ścieżkę diagnostyczną dla właścicieli firm, marketerów B2B, e-commerce managerów i osób odpowiedzialnych za stronę.
Najważniejsza zasada: dane strukturalne nie zastępują treści. Jeżeli w schema deklarujesz cenę, ocenę, autora, dostępność produktu, FAQ, breadcrumbs albo organizację, ta informacja musi być widoczna lub logicznie dostępna na stronie i zgodna z tym, co indeksuje Google.
Objaw: rich results nie pojawiają się mimo wdrożenia danych
Najczęstszy scenariusz wygląda tak: przed migracją strona miała widoczne elementy rozszerzone w wynikach Google, na przykład gwiazdki opinii, breadcrumbs, informacje o produkcie, cenę, dostępność, FAQ albo dane wydarzenia. Po wdrożeniu nowej wersji strony znaczniki nadal są obecne, ale rozszerzenia znikają z wyników wyszukiwania lub pojawiają się tylko dla części adresów.
W Google Search Console możesz zobaczyć spadek liczby prawidłowych elementów w raportach dotyczących danych strukturalnych, wzrost ostrzeżeń albo komunikaty o nieprawidłowych polach. Czasami raport nie pokazuje błędów, ale rich results nadal nie wracają. To ważne, ponieważ samo przejście testu technicznego nie gwarantuje wyświetlenia wyniku rozszerzonego.
Schema istnieje, ale jest niepełna
Nowy szablon generuje dane strukturalne bez części wymaganych lub rekomendowanych pól, na przykład bez ceny, dostępności, autora, daty publikacji albo elementów breadcrumb.
Schema nie pasuje do treści
W kodzie deklarowany jest produkt, recenzja, FAQ lub artykuł, ale widoczna treść strony nie potwierdza tych informacji albo została zmieniona podczas migracji.
Google widzi inną wersję strony
Dane strukturalne mogą być generowane po stronie JavaScript, ukryte przez błędy renderowania albo różnić się między HTML źródłowym a wyrenderowanym DOM.
Więcej kontekstu o problemach technicznych, które często występują po zmianie strony, znajdziesz w sekcji problemy SEO techniczne. Warto potraktować dane strukturalne jako część szerszej diagnostyki, a nie jako odizolowany fragment kodu.
Dlaczego migracja strony psuje dane strukturalne
Migracja rzadko polega wyłącznie na zmianie wyglądu. Zwykle obejmuje nowy CMS, nowy motyw, przebudowę szablonów, zmianę adresów URL, wdrożenie headless CMS, zmianę wtyczek SEO, nowe moduły produktowe, inny system opinii albo inne źródła danych. Każdy z tych elementów może wpłynąć na Schema.org.
Problem polega na tym, że dane strukturalne są często generowane automatycznie. Po migracji ta automatyzacja może działać nadal, ale na podstawie innych pól, pustych metadanych, błędnego mapowania albo domyślnych ustawień wtyczki. W efekcie kod wygląda profesjonalnie, ale opisuje nie tę stronę, nie ten produkt albo nie tę organizację.
Po migracji nie wystarczy sprawdzić strony głównej. Dane strukturalne trzeba zweryfikować na reprezentatywnych typach adresów: produktach, kategoriach, wpisach blogowych, stronach usług, landing page, stronach lokalnych, stronach autorów i podstronach z FAQ.
Dlaczego Google może nie pokazywać rich results?
- strona nie spełnia wytycznych dla danego typu wyniku rozszerzonego,
- dane strukturalne są poprawne składniowo, ale niezgodne z widoczną treścią,
- podstrona nie jest zaindeksowana albo Google wybrał inny kanoniczny adres,
- schema jest generowana tylko po stronie przeglądarki i nie jest stabilnie renderowana,
- typ danych nie kwalifikuje się do rich results w danym kontekście,
- Google nie ufa jakości treści, opinii lub danych produktowych,
- po migracji zmieniła się struktura adresów i raporty jeszcze nie odświeżyły danych.
Najczęstsze przyczyny błędnej lub niezgodnej schema po migracji
Zmiana szablonów bez aktualizacji mapowania pól
Nowy szablon produktu, usługi lub artykułu korzysta z innych pól niż poprzedni. W schema mogą pojawić się puste wartości, domyślne opisy, nieaktualne ceny albo błędne daty.
Duplikacja danych strukturalnych
Po migracji dane generuje jednocześnie motyw, wtyczka SEO, moduł e-commerce i dodatkowy skrypt. Google otrzymuje kilka sprzecznych deklaracji dla tej samej strony.
Nieprawidłowy typ schema
Strona usługi może być oznaczona jako Product, wpis poradnikowy jako NewsArticle, a strona kategorii jako pojedynczy produkt. To nie zawsze wywoła błąd składni, ale może wykluczyć rich results.
Niezgodność treści z JSON-LD
W danych strukturalnych występują opinie, pytania FAQ, ceny lub parametry, których użytkownik nie widzi na stronie. To częsty powód braku wyników rozszerzonych.
Błędne adresy URL po migracji
Schema wskazuje stare adresy, stare grafiki, poprzednie logo, błędny canonical albo nieistniejące identyfikatory @id. W efekcie Google ma problem z połączeniem encji.
Problemy z renderowaniem
Dane są wstrzykiwane przez JavaScript, ale Google nie zawsze otrzymuje je w tej samej formie. Dotyczy to szczególnie headless CMS, aplikacji SPA i rozbudowanych konfiguratorów.
Przykład problemu w e-commerce
Sklep po migracji na nowy silnik zachował schema Product, ale moduł cenowy zaczął ładować cenę dopiero po wyborze wariantu. W kodzie JSON-LD pozostaje cena domyślna albo pusta wartość, a na stronie użytkownik widzi inną kwotę. Test może pokazać ostrzeżenie, ale Google może nie wyświetlać ceny w wynikach, ponieważ dane nie są stabilne i jednoznaczne.
Przykład problemu w B2B
Firma usługowa po redesignie dodaje do wszystkich podstron znacznik Product, ponieważ tak działa szablon landing page. Strony ofertowe nie mają jednak ceny, dostępności ani typowych atrybutów produktu. W takim przypadku lepsze może być uporządkowanie danych Organization, LocalBusiness, WebPage, Service, BreadcrumbList oraz Article dla treści eksperckich. Dobór typu powinien wynikać z intencji strony, nie z tego, co da się technicznie wygenerować.
Jeżeli część problemów dotyczy konfiguracji WordPressa, motywu lub wtyczek SEO, pomocna może być analiza obszaru optymalizacja WordPress. W praktyce wiele błędów schema wynika z konfliktu między motywem, page builderem, WooCommerce i wtyczką SEO.
Diagnostyka krok po kroku
Diagnostyka powinna łączyć testy narzędziowe z ręczną oceną treści. Jeżeli sprawdzisz wyłącznie walidator, możesz przeoczyć najważniejszy problem: dane mogą być formalnie poprawne, ale nieuprawnione lub nieadekwatne.
- Wybierz reprezentatywne adresyNie badaj tylko strony głównej. Wybierz po kilka przykładów z każdego szablonu: produkt, kategoria, artykuł, usługa, FAQ, lokalizacja, strona autora, landing page.
- Sprawdź indeksację i canonicalZweryfikuj w Google Search Console, czy adres jest zaindeksowany, czy Google wybrał właściwy canonical i czy nie występują blokady robots.txt, noindex albo przekierowania.
- Porównaj HTML źródłowy z wyrenderowanym DOMSprawdź, czy dane strukturalne są obecne w źródle strony oraz po renderowaniu. Różnice mogą wskazywać na problem z JavaScript lub opóźnionym ładowaniem danych.
- Uruchom Rich Results TestSprawdź, które typy danych Google rozpoznaje jako kwalifikujące się do wyników rozszerzonych. Zwróć uwagę na błędy, ostrzeżenia i typy niewspierane w rich results.
- Uruchom Schema Markup ValidatorTo narzędzie pomaga ocenić zgodność ze Schema.org szerzej niż tylko pod kątem wyników rozszerzonych Google. Przydaje się do wykrywania błędnej struktury i relacji między encjami.
- Porównaj dane z treścią widoczną na stronieSprawdź ręcznie, czy cena, dostępność, opinie, pytania FAQ, autor, data, nazwa produktu i breadcrumbs są zgodne z tym, co widzi użytkownik.
- Sprawdź duplikaty i konfliktyUstal, czy schema nie jest generowana przez kilka źródeł jednocześnie. Konflikty między wtyczkami są jedną z najczęstszych przyczyn problemów po migracji.
- Zweryfikuj dane w Google Search ConsolePorównaj raporty przed i po migracji. Sprawdź, czy problem dotyczy pojedynczych adresów, konkretnego szablonu czy całego serwisu.
Jeżeli rich results zniknęły po migracji, nie zakładaj automatycznie kary ani spadku jakości domeny. Najpierw sprawdź techniczne podstawy: indeksację, canonical, renderowanie, zgodność danych z treścią i konflikty źródeł schema.
Tabela diagnostyczna: co sprawdzić i jak interpretować wyniki
| Obszar diagnostyki | Co sprawdzić | Możliwy objaw | Rekomendowane działanie |
|---|---|---|---|
| Indeksacja | Status adresu w Google Search Console, canonical wybrany przez Google, blokady noindex i robots.txt | Schema jest poprawna, ale adres nie pojawia się w wynikach lub Google indeksuje inną wersję URL | Napraw canonical, przekierowania, linkowanie wewnętrzne i blokady indeksacji przed analizą rich results |
| Typ danych | Czy typ schema odpowiada realnej funkcji strony | Strona usługi oznaczona jako Product albo artykuł jako typ nieadekwatny do treści | Dopasuj typy do intencji podstrony, na przykład Service, Article, WebPage, Product, BreadcrumbList |
| Zgodność z treścią | Czy pola w JSON-LD są widoczne lub potwierdzone na stronie | W schema są opinie, ceny, FAQ lub autor, których nie ma w widocznej treści | Usuń nieuprawnione pola albo dodaj brakujące informacje w sposób dostępny dla użytkownika |
| Duplikacja schema | Czy dane generuje motyw, wtyczka SEO, WooCommerce, page builder lub skrypt zewnętrzny | Kilka obiektów Product, Organization lub BreadcrumbList z różnymi wartościami | Wyznacz jedno źródło prawdy i wyłącz duplikujące moduły |
| Renderowanie | Różnice między HTML źródłowym, DOM i wersją pobraną przez Google | Test widzi inne dane niż kod źródłowy albo dane znikają po interakcji | Generuj kluczowe dane po stronie serwera lub zadbaj o stabilne renderowanie |
| Adresy i identyfikatory | @id, url, image, logo, sameAs, breadcrumb item | Schema odwołuje się do starych adresów po migracji lub do zasobów 404 | Zaktualizuj identyfikatory encji, grafiki, logo i ścieżki breadcrumb |
| Dane produktowe | price, priceCurrency, availability, aggregateRating, review, sku, brand | Brak cen w rich results, błędy w produktach, niespójne warianty | Ujednolić źródła danych produktowych i mapowanie wariantów |
| Treści FAQ | Czy pytania i odpowiedzi w schema są identyczne z treścią strony | FAQ jest w kodzie, ale nie pojawia się w wynikach lub raport pokazuje problemy | Stosuj FAQ tylko tam, gdzie pytania są faktycznie widoczne i pomocne dla użytkownika |
Rekomendowane działania naprawcze
Naprawa danych strukturalnych powinna zaczynać się od uporządkowania źródeł danych, a dopiero później od poprawiania pojedynczych pól. Jeżeli ten sam typ schema jest generowany w kilku miejscach, każda kolejna poprawka może tworzyć nowe konflikty.
1. Ustal jedno źródło generowania schema
W WordPressie najczęściej dane strukturalne generuje wtyczka SEO, motyw, WooCommerce, moduł opinii, page builder albo dedykowany plugin schema. Po migracji warto zdecydować, które narzędzie odpowiada za konkretne typy danych. Przykładowo: wtyczka SEO może generować Organization, WebSite i BreadcrumbList, WooCommerce dane Product, a dedykowany moduł tylko elementy specyficzne dla branży.
- wyłącz duplikujące typy danych w motywie lub wtyczce,
- sprawdź, czy szablony nie dodają ręcznie starego JSON-LD,
- udokumentuj, które narzędzie generuje dany typ schema,
- nie mieszaj kilku wersji danych Product, Review lub FAQ na jednej stronie.
2. Dopasuj typ schema do celu podstrony
Nie każda podstrona powinna być oznaczona jako Product. W B2B częstym błędem jest traktowanie usług jak produktów tylko dlatego, że daje to nadzieję na bogatszy wynik. Google ocenia jednak spójność danych z treścią i kontekstem strony. Strona usługi może korzystać z danych Service, Organization, LocalBusiness, WebPage, BreadcrumbList oraz Article, jeśli zawiera treść poradnikową lub ekspercką.
Jeżeli nie masz pewności, co oznaczają poszczególne typy i pola, warto korzystać z uporządkowanej wiedzy w słowniku pojęć. Przy danych strukturalnych nie chodzi o dodanie jak największej liczby znaczników, ale o precyzyjne opisanie strony w sposób zgodny z jej zawartością.
3. Usuń dane, których nie potwierdza treść
To jeden z najważniejszych etapów. Jeżeli schema zawiera informacje o ocenach, pytaniach FAQ, autorze, cenach, dostępności, czasie trwania wydarzenia albo wariantach produktu, użytkownik powinien móc je zweryfikować na stronie. Ukrywanie danych wyłącznie w JSON-LD zwiększa ryzyko braku kwalifikacji do rich results.
Nie próbuj odzyskiwać rich results przez sztuczne dodawanie pól. Jeżeli strona nie ma recenzji, nie dodawaj aggregateRating. Jeżeli nie prezentuje pytań i odpowiedzi, nie dodawaj FAQPage. Jeżeli nie sprzedaje konkretnego produktu, nie wymuszaj Product.
4. Zaktualizuj adresy, obrazy i identyfikatory encji
Po migracji często zostają stare adresy w polach url, image, logo, sameAs, item oraz @id. Takie błędy nie zawsze powodują komunikat krytyczny, ale osłabiają spójność danych. Szczególnie ważne są identyfikatory @id dla organizacji, strony internetowej, produktów, autorów i breadcrumbs. Powinny być stabilne, kanoniczne i zgodne z aktualną strukturą serwisu.
- sprawdź, czy logo w Organization działa i ma odpowiedni format,
- zweryfikuj, czy image nie prowadzi do pliku usuniętego podczas migracji,
- upewnij się, że breadcrumb item wskazuje aktualne adresy,
- zaktualizuj linki sameAs do profili firmowych,
- usuń odniesienia do domen testowych, stagingowych i starych subdomen.
5. Zweryfikuj zgodność z wytycznymi Google dla rich results
Schema.org jest szerszym standardem niż rich results w Google. Możesz mieć poprawne dane strukturalne, które nie kwalifikują się do żadnego widocznego rozszerzenia. Dlatego trzeba oddzielić dwa poziomy: poprawność semantyczną oraz kwalifikację do konkretnego wyniku rozszerzonego.
Dla przykładu, oznaczenie danych organizacji może pomóc w zrozumieniu encji, ale nie oznacza automatycznie widocznego elementu rozszerzonego. Podobnie nie każde FAQ będzie prezentowane w wynikach. Google ogranicza widoczność niektórych formatów i uzależnia ją od typu strony, jakości treści, zapytania użytkownika oraz zaufania do serwisu.
6. Przetestuj wdrożenie na szablonach, nie tylko na pojedynczym URL
Naprawa jednej podstrony nie rozwiązuje problemu, jeśli błędna logika siedzi w szablonie. Po poprawkach trzeba przetestować różne warianty: produkt z ceną promocyjną, produkt niedostępny, produkt z wariantami, artykuł z autorem, wpis bez autora, strona usługi, kategoria bez opisu, kategoria z opisem, landing page z FAQ.
W większych serwisach dobrym podejściem jest audyt próbkowany. Wybiera się grupy adresów według typów szablonów i sprawdza, czy każdy szablon generuje przewidywalne, spójne i zgodne z treścią dane. Taki zakres może być częścią szerszego audytu SEO, zwłaszcza po migracji, redesignie lub zmianie CMS.
Lista kontrolna po naprawie danych strukturalnych
Po wdrożeniu poprawek nie kończ pracy na zielonym wyniku w jednym narzędziu. Rich results zależą od indeksacji, jakości danych, zgodności z treścią i ponownego przetworzenia strony przez Google.
- Sprawdź, czy każdy typ podstrony ma właściwy typ schema.
- Usuń duplikaty generowane przez motyw, wtyczki lub stare skrypty.
- Porównaj JSON-LD z treścią widoczną dla użytkownika.
- Zweryfikuj dane w HTML źródłowym i po renderowaniu.
- Sprawdź, czy adresy w schema są aktualne i kanoniczne.
- Upewnij się, że obrazy, logo i linki w danych strukturalnych nie zwracają 404.
- Zweryfikuj breadcrumbs po zmianie struktury URL.
- Sprawdź, czy pola cenowe i dostępności są zgodne z danymi w sklepie.
- Przetestuj kilka adresów z każdego szablonu, nie tylko jeden przykład.
- Poproś Google o ponowne sprawdzenie problemów w Search Console, jeśli raport to umożliwia.
- Monitoruj raporty danych strukturalnych przez kilka tygodni po wdrożeniu.
- Porównaj widoczność rich results na zapytaniach brandowych i niebrandowych.
Jak długo czekać na powrót rich results?
Nie ma jednej gwarantowanej daty. Google musi ponownie zaindeksować adresy, przetworzyć dane i zdecydować, czy strona kwalifikuje się do rozszerzenia. Dla małych serwisów pierwsze zmiany mogą być widoczne po kilku dniach, dla dużych sklepów lub serwisów po migracji proces może trwać kilka tygodni. Ważne jest, aby w tym czasie nie wprowadzać chaotycznych zmian w schema co kilka dni, bo utrudnia to ocenę efektu.
Czego nie robić podczas naprawy?
- nie kopiuj znaczników z konkurencji bez dopasowania do własnej treści,
- nie dodawaj opinii, których nie ma na stronie,
- nie oznaczaj każdej podstrony jako Product tylko po to, aby uzyskać bogatszy wynik,
- nie zostawiaj kilku źródeł danych strukturalnych dla tego samego typu,
- nie ignoruj canonical i indeksacji, bo schema na nieindeksowanej stronie nie przyniesie efektu,
- nie oceniaj sukcesu wyłącznie po walidatorze, bez sprawdzenia treści i raportów GSC.
Kiedy warto skonsultować problem z ekspertem?
Konsultacja ma sens wtedy, gdy problem dotyczy wielu szablonów, migracja była rozległa, rich results zniknęły w całym serwisie albo zespół techniczny nie ma pewności, które źródło generuje konkretne dane. W takich przypadkach pojedyncze poprawki w JSON-LD często nie wystarczą. Trzeba przeanalizować architekturę szablonów, sposób renderowania, canonicale, dane produktowe, logikę wtyczek i raporty Search Console.
Po migracji spadła liczba prawidłowych elementów
Jeżeli raporty w Google Search Console pokazują gwałtowny spadek dla produktów, breadcrumbs, FAQ lub artykułów, warto sprawdzić, czy problem nie wynika z nowego szablonu.
Walidatory pokazują różne wyniki
Rozbieżności między Rich Results Test, Schema Markup Validator, HTML źródłowym i DOM zwykle wymagają analizy renderowania oraz źródeł generowania schema.
Masz sklep lub serwis z wieloma typami podstron
W e-commerce i serwisach B2B błąd w jednym komponencie może powielać się na setkach lub tysiącach adresów, dlatego ważna jest diagnostyka szablonowa.
Zespół wdrożeniowy poprawia kod, ale rich results nie wracają
To sygnał, że problem może leżeć nie w składni, ale w zgodności danych z treścią, indeksacji, canonicalach albo jakości źródłowych danych.
W RankHero analizujemy dane strukturalne jako element SEO technicznego: sprawdzamy poprawność wdrożenia, zgodność z treścią, wpływ migracji, konflikty wtyczek, indeksację, canonicale i renderowanie. Dzięki temu rekomendacje są możliwe do przekazania zespołowi technicznemu w formie konkretnych zadań, a nie ogólnych sugestii.
Chcesz sprawdzić, dlaczego schema po migracji nie działa poprawnie?
Przeanalizujemy dane strukturalne, szablony, indeksację i raporty Google Search Console. Wskażemy, które elementy blokują rich results i jak je naprawić bez chaotycznych zmian w kodzie.
FAQ
Czy poprawna schema gwarantuje rich results w Google?
Nie. Poprawność techniczna jest warunkiem podstawowym, ale Google sam decyduje, czy wyświetli wynik rozszerzony. Znaczenie mają także zgodność danych z treścią, typ strony, jakość treści, indeksacja, canonical, zapytanie użytkownika i aktualne wytyczne dla danego formatu.
Dlaczego rich results zniknęły po migracji, skoro dane strukturalne nadal są w kodzie?
Po migracji mogło dojść do zmiany szablonów, źródeł danych, adresów URL, canonicali lub sposobu renderowania. Dane mogą być obecne, ale niezgodne z treścią, zdublowane, częściowo puste albo odwołujące się do starych zasobów. Google może wtedy nie kwalifikować strony do rozszerzeń.
Czy ostrzeżenia w Rich Results Test trzeba zawsze naprawiać?
Ostrzeżenia nie zawsze blokują wynik rozszerzony, ale często wskazują na pola, które poprawiają kompletność danych. Warto ocenić je priorytetowo. Jeżeli ostrzeżenia dotyczą kluczowych informacji dla produktu, artykułu lub organizacji, ich naprawa może zwiększyć jakość wdrożenia.
Czy można mieć kilka typów schema na jednej stronie?
Tak, o ile opisują różne aspekty tej samej strony i nie są ze sobą sprzeczne. Przykładowo strona produktu może mieć Product, BreadcrumbList, Organization i WebSite. Problem zaczyna się wtedy, gdy kilka narzędzi generuje różne wersje tego samego obiektu, na przykład dwa różne znaczniki Product z inną ceną.
Czy FAQPage nadal ma sens?
Tak, ale tylko tam, gdzie pytania i odpowiedzi są rzeczywiście widoczne, pomocne i zgodne z treścią strony. Nie warto dodawać FAQPage masowo na każdej podstronie. Google ogranicza widoczność niektórych wyników FAQ, dlatego ten znacznik powinien wynikać z użyteczności treści, a nie wyłącznie z chęci uzyskania większego wyniku w SERP.
Jak sprawdzić, czy schema jest generowana przez wtyczkę, motyw czy własny kod?
Najprościej porównać kod źródłowy, ustawienia wtyczek SEO, konfigurację motywu, moduły e-commerce i szablony. W WordPressie warto tymczasowo zidentyfikować wszystkie źródła JSON-LD i ustalić, które z nich odpowiada za Organization, Product, BreadcrumbList, Article lub FAQPage. Przy większych serwisach lepiej zrobić to na środowisku testowym.
Czy zmiana adresów URL po migracji wpływa na dane strukturalne?
Tak. Schema często zawiera pola url, @id, image, logo i elementy breadcrumb. Jeżeli po migracji wskazują stare adresy, domenę testową, zasoby 404 lub niekanoniczne wersje URL, dane stają się niespójne. To może utrudnić Google interpretację strony i encji.
Czy dane strukturalne powinny być w HTML źródłowym?
Najbezpieczniej, gdy kluczowe dane strukturalne są dostępne w HTML źródłowym lub stabilnie renderowane po stronie serwera. Dane wstrzykiwane przez JavaScript mogą działać, ale zwiększają ryzyko rozbieżności między tym, co widzi użytkownik, przeglądarka i Googlebot.
Kiedy po poprawkach zgłosić adresy do ponownego sprawdzenia?
Po wdrożeniu poprawek warto najpierw przetestować reprezentatywne adresy i upewnić się, że problem został rozwiązany na poziomie szablonu. Następnie można skorzystać z narzędzi w Google Search Console, poprosić o walidację problemu lub inspekcję wybranych URL. W dużych serwisach trzeba też monitorować raporty przez kolejne tygodnie.
Czy audyt SEO obejmuje dane strukturalne?
Tak, jeśli zakres audytu obejmuje SEO techniczne. Dane strukturalne powinny być analizowane razem z indeksacją, canonicalami, renderowaniem, architekturą informacji, linkowaniem wewnętrznym i jakością szablonów. Dzięki temu łatwiej odróżnić błąd schema od problemu z całą migracją strony.