Raport o stanie stron AMP

Ten raport pomaga w naprawianiu błędów, które uniemożliwiają wyświetlanie stron AMP w wynikach wyszukiwania Google z funkcjami związanymi z AMP.

Widok główny zawiera wszystkie strony AMP z błędami znalezionymi przez Google w Twojej witrynie, pogrupowane według tych błędów. Aby wyświetlić szczegółowe informacje na temat błędu, w tym przykładową listę stron, na których on występuje, oraz instrukcje, jak go naprawić, a także aby rozpocząć proces powiadamiania Google o zastosowanych poprawkach, kliknij ten błąd.

Wykresy przedstawiające zakres błędów i poprawek znajdziesz na stronie stanu.

Dlaczego ta lista zawiera tylko próbkę danych? Pokazujemy tyle stron zawierających błędy, ile możemy. Obowiązuje nas jednak nieprzekraczalny limit 1000 adresów URL, które możemy wymienić w tabeli. Poza tym mogą jeszcze istnieć inne strony, których nie wykryliśmy lub których z jakiegoś powodu nie uwzględniliśmy.

OTWÓRZ RAPORT O STRONACH AMP

 

Raport o stanie AMP w Search Console – szkolenie z Google Search Console

Na co zwrócić uwagę

W sytuacji idealnej raport powinien zawierać:

Lista problemów związanych z AMP

Oprócz standardowych błędów AMP raport może wskazywać dodatkowe błędy opisane poniżej.

Problemy związane z AMP wynikające z wymagań Google
Problem Opis
Niezgodność treści: brak umieszczonego filmu Film umieszczony na stronie kanonicznej jest niedostępny w jej wersji AMP. Zalecamy umieszczenie na stronie AMP wszystkich ważnych zasobów treści, które zawiera strona kanoniczna. Pamiętaj, że film jest wykrywany na podstawie adresu URL. To ostrzeżenie wyświetli się wtedy, gdy do tego samego filmu prowadzą dwa różne adresy URL.
Rozmiar obrazu mniejszy niż zalecany Uporządkowane dane na stronie AMP odnoszą się do obrazu, który ma rozmiar mniejszy od zalecanego. Może to uniemożliwić wyświetlanie takiej strony razem ze wszystkimi funkcjami standardu AMP w wyszukiwarce Google. Poza tym mogą nie wyświetlać się karty Discover z dużymi obrazami, co będzie skutkować zmniejszeniem ruchu w witrynie i mniejszym zaangażowaniem użytkowników. Aby rozwiązać problem, użyj większego obrazu (zgodnie z naszymi wytycznymi).
Niezgodność domeny strony AMP Strona AMP znajduje się w innej domenie niż jej wersja kanoniczna. Może to być mylące dla użytkowników korzystających z wyszukiwarki na urządzeniach mobilnych, którzy widzą jedną domenę URL w wynikach wyszukiwania, a inną po otwarciu strony w czytniku AMP. (Nie ma to wpływu na indeksowanie ani na pozycję strony w rankingu).
Nie znaleziono adresu URL (404) Nie znaleziono żądanego adresu URL strony AMP. Dowiedz się więcej o naprawianiu stron 404
Błąd serwera (5xx) Podczas wysyłania żądania wyświetlenia strony AMP wystąpił nieokreślony błąd serwera 5xx. Więcej informacji o błędach serwera
Strona zablokowana przez plik robots.txt Żądany adres URL strony AMP został zablokowany przez regułę w pliku robots.txt.
Problem z indeksowaniem Nieokreślony błąd indeksowania strony AMP. Spróbuj rozwiązać problem z adresem URL strony AMP za pomocą narzędzia do sprawdzania adresów URL
URL strony AMP w odniesieniu nie jest stroną AMP Strona kanoniczna zawiera odniesienie do strony AMP, która w rzeczywistości nie jest stroną AMP. Więcej informacji o tym, jak strona inna niż AMP powinna odsyłać do strony AMP
URL strony AMP w odniesieniu jest samodzielną kanoniczną stroną AMP Strona kanoniczna prowadzi do samodzielnej strony AMP. Nie można odsyłać do samodzielnej strony AMP jako do wersji AMP strony. Więcej informacji o tym, jak strona inna niż AMP powinna odsyłać do strony AMP
URL zawiera tag „noindex” Strona AMP jest blokowana przy użyciu instrukcji „noindex”. Google nie może indeksować takich stron. Usuń instrukcję „noindex” lub usuń odniesienie do blokowanej strony.
Minął termin „unavailable_after” dla tej strony W przypadku strony AMP istnieje metatag lub instrukcja „unavailable_after” z datą w przeszłości, co wskazuje, że strony nie należy wyświetlać. Zaktualizuj tag, by zawierał datę w przyszłości, albo go usuń.
Adres kanoniczny ma nieprawidłowy URL Strona kanoniczna zawiera odniesienie do wersji strony AMP, które korzysta z nieprawidłowo sformatowanego adresu URL. Więcej informacji o prawidłowym tworzeniu odniesień do stron AMP
Błąd strony kanonicznej relacji w technologii AMP

Strona używa nieprawidłowego odniesienia do strony relacji w technologii AMP jako do własnej wersji AMP. Nie jest to dozwolone, ponieważ strona relacji w technologii AMP jest z definicji samodzielną kanoniczną stroną AMP – musi zawierać odniesienie do siebie w tagu <rel="canonical">. Nie może być wyświetlana jako wersja AMP innej strony.

Problemy z protokołem Signed Exchange

Zarówno raport o stanie stron AMP, jak i raport narzędzia do sprawdzania adresów URL może wskazywać problemy ze stronami AMP korzystającymi z protokołu Signed Exchange.

Wyświetlanie szczegółów dotyczących problemu z protokołem Signed Exchange

Informacje o protokole Signed Exchange powiązanym z daną stroną AMP możesz znaleźć w wielu miejscach:

  • W narzędziu do sprawdzania adresów URL kliknij problem w sekcji Szczegóły wersji AMP.
  • W raporcie o stanie stron AMP kliknij adres URL w tabeli szczegółów problemu.

Sprawdzanie, czy strona AMP korzysta z protokołu Signed Exchange

Aby sprawdzić, czy system Google wykrył na stronie AMP nagłówki lub ładunki Signed Exchange:

  1. Sprawdź adres URL strony AMP (użyj narzędzia do sprawdzania adresów URL, by zbadać konkretny adres URL, albo w raporcie o stanie stron AMP kliknij ikonę inspekcji  obok adresu URL w tabeli „Szczegóły problemów”).
  2. Na stronie wyników kliknij Wyświetl zindeksowaną stronę, by otworzyć panel boczny z dodatkowymi informacjami.
  3. Kliknij kartę Więcej informacji.
  4. Pod etykietą Signed Exchange będzie podany stan wskazujący, czy system Google wykrył na danej stronie AMP komponenty Signed Exchange.

Lista problemów z protokołem Signed Exchange

Podczas korzystania przez stronę AMP z protokołu Signed Exchange mogą wystąpić takie błędy:

Podpisana komunikacja jest nieprawidłowa

Odpowiedź HTTP deklarowała zgodność z protokołem Signed Exchange, ale nie spełniała wymagań serwera Google AMP Cache. W efekcie strona będzie prezentowana użytkownikom bez żadnych informacji z podpisu.

Wpływ na Twoją witrynę:

Strona będzie wyświetlana w przeglądarce AMP z adresem URL Google, a nie z jej adresem pierwotnym.

Dalsze kroki:

Usunięcie tego błędu jest opcjonalne. Strony, na których on występuje, nadal będą się prawidłowo wyświetlać w przeglądarce AMP. Jeśli chcesz, by ta strona otwierała się z jej podpisanym adresem URL, czytaj dalej.

Ten błąd może wystąpić z kilku powodów, m.in.:

Jeśli korzystasz z protokołu Signed Exchange udostępnianego przez dostawcę usług, poproś go o pomoc.

Jeśli korzystasz z narzędzia AMP Packager:

  • Upewnij się, że używasz najnowszej wersji narzędzia AMP Packager.
  • Jeśli tak, zgłoś błąd.

Ładunek podpisanej komunikacji zawiera błąd analizy

Odpowiedź HTTP deklarowała zgodność z protokołem Signed Exchange, ale jej „ładunek” (czyli treść) nie spełniał wymagań serwera Google AMP Cache. W efekcie strona będzie prezentowana użytkownikom bez żadnych informacji z podpisu.

Wpływ na Twoją witrynę:

Strona będzie wyświetlana w przeglądarce AMP z adresem URL Google, a nie z jej adresem pierwotnym.

Dalsze kroki:

Usunięcie tego błędu jest opcjonalne. Strony, na których on występuje, nadal będą się prawidłowo wyświetlać w przeglądarce AMP. Jeśli chcesz, by ta strona otwierała się z jej podpisanym adresem URL, czytaj dalej.

Ten błąd może wystąpić z kilku powodów:

  • Sprawdź, czy kod HTML nie zawiera nieprawidłowego kodowania UTF-8. Aby zweryfikować parametr $URL, wykonaj polecenie curl $URL | iconv -f UTF-8 -t UTF-8 >/dev/null i zobacz, czy nie pojawią się jakieś komunikaty o błędach, np. „illegal input sequence” (nieprawidłowa sekwencja danych wejściowych). Jeśli się pojawią, dopilnuj, by dokument miał prawidłowe kodowanie UTF-8. Dwa najczęstsze źródła znaków wielobajtowych to tekst w języku innym niż angielski i spacje.
  • Sprawdź, czy kod HTML nie zawiera wartości U+0000 NULL lub znaku Unicode powodującego błąd analizy HTML.
  • Sprawdź, czy kod HTML nie zmienił się po wywołaniu polecenia transform -config NONE. Istnieją dwie najczęstsze przyczyny tej zmiany:

Nagłówek „header_name” ładunku w podpisanej komunikacji zawiera nieprawidłową wartość

Odpowiedź HTTP deklarowała zgodność z protokołem Signed Exchange, ale zawierała nagłówek, który nie spełniał jednego z wymagań serwera Google AMP Cache. W efekcie strona będzie prezentowana użytkownikom bez żadnych informacji z podpisu.

Wpływ na Twoją witrynę:

Strona będzie wyświetlana w przeglądarce AMP z adresem URL Google, a nie z jej adresem pierwotnym.

Dalsze kroki:

Usunięcie tego błędu jest opcjonalne. Strony, na których on występuje, nadal będą się prawidłowo wyświetlać w przeglądarce AMP. Jeśli chcesz, by ta strona otwierała się z jej podpisanym adresem URL, czytaj dalej.

Jeśli korzystasz z protokołu Signed Exchange udostępnianego przez dostawcę usług, poproś go o pomoc.

Jeśli korzystasz z narzędzia AMP Packager:

  • Upewnij się, że używasz najnowszej wersji narzędzia AMP Packager.
  • Jeśli tak, zgłoś błąd.

Brakuje wymaganego nagłówka „header_name” ładunku w podpisanej komunikacji

Odpowiedź HTTP deklarowała zgodność z protokołem Signed Exchange, ale brakowało w niej wskazanego nagłówka, który jest niezbędny zgodnie ze specyfikacją tego protokołu lub z wymaganiami serwera Google AMP Cache. W efekcie strona będzie prezentowana użytkownikom bez żadnych informacji z podpisu.

Wpływ na Twoją witrynę:

Strona będzie wyświetlana w przeglądarce AMP z adresem URL Google, a nie z jej adresem pierwotnym.

Dalsze kroki:

Usunięcie tego błędu jest opcjonalne. Strony, na których on występuje, nadal będą się prawidłowo wyświetlać w przeglądarce AMP. Jeśli chcesz, by ta strona otwierała się z jej podpisanym adresem URL, czytaj dalej.

Jeśli korzystasz z protokołu Signed Exchange udostępnianego przez dostawcę usług, poproś go o pomoc.

Jeśli korzystasz z narzędzia AMP Packager:

  • Upewnij się, że używasz najnowszej wersji narzędzia AMP Packager.
  • Jeśli tak, zgłoś błąd.

Nie można przeanalizować nagłówka podpisu w podpisanej komunikacji

Odpowiedź HTTP deklarowała zgodność z protokołem Signed Exchange, ale zawierała nagłówek podpisu niezgodny ze specyfikacją tego protokołu. W efekcie strona będzie prezentowana użytkownikom bez żadnych informacji z podpisu.

Wpływ na Twoją witrynę:

Strona będzie wyświetlana w przeglądarce AMP z adresem URL Google, a nie z jej adresem pierwotnym.

Dalsze kroki:

Usunięcie tego błędu jest opcjonalne. Strony, na których on występuje, nadal będą się prawidłowo wyświetlać w przeglądarce AMP. Jeśli chcesz, by ta strona otwierała się z jej podpisanym adresem URL, czytaj dalej.

Jeśli korzystasz z protokołu Signed Exchange udostępnianego przez dostawcę usług, poproś go o pomoc.

Jeśli korzystasz z narzędzia AMP Packager:

  • Upewnij się, że używasz najnowszej wersji narzędzia AMP Packager.
  • Jeśli tak, zgłoś błąd.

Parametr „parameter_name” nagłówka podpisu w podpisanej komunikacji jest nieprawidłowy

Odpowiedź HTTP deklarowała zgodność z protokołem Signed Exchange, ale nagłówek podpisu zawierał wartość wskazanego parametru niezgodną ze specyfikacją tego protokołu. W efekcie strona będzie prezentowana użytkownikom bez żadnych informacji z podpisu.

Wpływ na Twoją witrynę:

Strona będzie wyświetlana w przeglądarce AMP z adresem URL Google, a nie z jej adresem pierwotnym.

Dalsze kroki:

Usunięcie tego błędu jest opcjonalne. Strony, na których on występuje, nadal będą się prawidłowo wyświetlać w przeglądarce AMP. Jeśli chcesz, by ta strona otwierała się z jej podpisanym adresem URL, czytaj dalej.

Jeśli korzystasz z protokołu Signed Exchange udostępnianego przez dostawcę usług, poproś go o pomoc.

Jeśli korzystasz z narzędzia AMP Packager:

  • Upewnij się, że używasz najnowszej wersji narzędzia AMP Packager.
  • Jeśli tak, zgłoś błąd.

Daty w podpisanej komunikacji są nieprawidłowe

Odpowiedź HTTP deklarowała zgodność z protokołem Signed Exchange, ale nagłówek podpisu zawierał wartość parametru date lub expires, która nie spełniała wymagań tego protokołu lub wymagań serwera Google AMP Cache. (W szczególności podpis musi być ważny w chwili jego pobrania i jeszcze przez co najmniej cztery dni). W efekcie strona będzie prezentowana użytkownikom bez żadnych informacji z podpisu.

Wpływ na Twoją witrynę:

Strona będzie wyświetlana w przeglądarce AMP z adresem URL Google, a nie z jej adresem pierwotnym.

Dalsze kroki:

Usunięcie tego błędu jest opcjonalne. Strony, na których on występuje, nadal będą się prawidłowo wyświetlać w przeglądarce AMP. Jeśli chcesz, by ta strona otwierała się z jej podpisanym adresem URL, czytaj dalej.

Jeśli korzystasz z protokołu Signed Exchange udostępnianego przez dostawcę usług, poproś go o pomoc.

Jeśli korzystasz z narzędzia AMP Packager, ten błąd mógł wystąpić z kilku powodów:

  • Sprawdź, czy zwrotny serwer proxy interfejsu nie przechowuje zbyt długo w pamięci podręcznej odpowiedzi zgodnych z protokołem Signed Exchange. Wyślij kilka żądań tej strony z użyciem polecenia curl -H 'Accept: application/signed-exchange;v=b3' -H 'AMP-Cache-Transform: any' i odszukaj we wszystkich odpowiedziach parametr „date=”. Jego wartość powinna być za każdym razem inna.
  • Upewnij się, że używasz najnowszej wersji narzędzia AMP Packager.
  • Jeśli wykluczysz wszystkie powyższe przyczyny, możliwe, że błąd występuje w narzędziu AMP Packager. W takiej sytuacji zgłoś błąd.

Nie można przeanalizować łańcucha certyfikatów, do którego odnosi się podpisana komunikacja „cert-url”

Odpowiedź HTTP deklarowała zgodność z protokołem Signed Exchange, ale zawierała wartość parametru „cert-url” niezgodną ze specyfikacją tego protokołu. W efekcie strona będzie prezentowana użytkownikom bez żadnych informacji z podpisu.

Wpływ na Twoją witrynę:

Strona będzie wyświetlana w przeglądarce AMP z adresem URL Google, a nie z jej adresem pierwotnym.

Dalsze kroki:

Usunięcie tego błędu jest opcjonalne. Strony, na których on występuje, nadal będą się prawidłowo wyświetlać w przeglądarce AMP. Jeśli chcesz, by ta strona otwierała się z jej podpisanym adresem URL, czytaj dalej.

Jeśli korzystasz z protokołu Signed Exchange udostępnianego przez dostawcę usług, poproś go o pomoc.

Jeśli korzystasz z narzędzia AMP Packager:

  • Upewnij się, że używasz najnowszej wersji narzędzia AMP Packager.
  • Jeśli tak, zgłoś błąd.

Łańcuch certyfikatów, do którego odnosi się „cert-url”, jest nieprawidłowy dla podpisanej komunikacji

Odpowiedź HTTP deklarowała zgodność z protokołem Signed Exchange, ale zawierała wartość parametru „cert-url” nieprawidłową w świetle specyfikacji tego protokołu. W efekcie strona będzie prezentowana użytkownikom bez żadnych informacji z podpisu.

Wpływ na Twoją witrynę:

Strona będzie wyświetlana w przeglądarce AMP z adresem URL Google, a nie z jej adresem pierwotnym.

Dalsze kroki:

Usunięcie tego błędu jest opcjonalne. Strony, na których on występuje, nadal będą się prawidłowo wyświetlać w przeglądarce AMP. Jeśli chcesz, by ta strona otwierała się z jej podpisanym adresem URL, czytaj dalej.

Jeśli korzystasz z protokołu Signed Exchange udostępnianego przez dostawcę usług, poproś go o pomoc.

Jeśli korzystasz z narzędzia AMP Packager, ten błąd mógł wystąpić z kilku powodów. Sprawdź te elementy:

  • Sprawdź, czy plik CertFile na pewno zawiera pełną listę obejmującą certyfikat wierzchołka ścieżki oraz certyfikaty pośrednie.
  • Sprawdź, czy narzędzie AMP Packager nie zostało uruchomione z flagą -development lub -invalidcert. W trybie produkcyjnym narzędzie AMP Packager będzie weryfikować kilka aspektów certyfikatu.
  • Sprawdź, czy zwrotny serwer proxy interfejsu nie przechowuje adresów URL /amppkg/cert/ w pamięci podręcznej przez czas dłuższy niż określony parametrem max-age.
  • Sprawdź, czy zwrotny serwer proxy interfejsu nie modyfikuje nagłówków pamięci podręcznej. Mogłoby to spowodować zbyt długie przechowywanie tych łańcuchów certyfikatów w pamięci podręcznej przez nadrzędny serwer proxy. Aby wykonać test, sprawdź odpowiedni adres URL /amppkg/cert/ w domenie swojego wewnętrznego systemu zarządzania pakietami, pobierz ten adres razem z nagłówkami odpowiedzi (np. za pomocą polecenia curl -i) i porównaj nagłówki odpowiedzi z nagłówkami zwróconymi przez serwer proxy interfejsu.
  • Sprawdź, czy certyfikat zawiera sygnaturę czasową podpisanego certyfikatu (SCT), np. za pomocą narzędzia openssl x509. Jeśli jej nie zawiera, skontaktuj się z urzędem certyfikacji.
  • Upewnij się, że używasz najnowszej wersji narzędzia AMP Packager.
  • Jeśli wykluczysz wszystkie powyższe przyczyny, możliwe, że błąd występuje w narzędziu AMP Packager. W takiej sytuacji zgłoś błąd.

Nie można przeanalizować podpisanej komunikacji

Odpowiedź HTTP zawierała nagłówek „content-type” application/signed-exchange;v=b3, ale jej treści nie udało się wyodrębnić. Przyczyną może być niespełnianie przez nią ogólnych wymagań tego typu lub nieprawidłowe zakodowanie jej ładunku w drzewie skrótów.

Wpływ na Twoją witrynę:

Jeśli strona ma odpowiednik inny niż AMP, wyszukiwarka Google w zamian go zindeksuje. W przeciwnym razie strona może się nie pojawić w wyszukiwarce Google.

Dalsze kroki:

Jeśli korzystasz z protokołu Signed Exchange udostępnianego przez dostawcę usług, poproś go o pomoc.

Jeśli korzystasz z narzędzia AMP Packager, ten błąd mógł wystąpić z kilku powodów:

  • Sprawdź, czy zwrotny serwer proxy interfejsu nie zmienia odpowiedzi z systemu zarządzania pakietami. Aby wykryć błędny adres URL, sprawdź odpowiedni adres URL /priv/doc w domenie swojego wewnętrznego systemu zarządzania pakietami i przetestuj go za pomocą narzędzia dump-signedexchange. Jeśli odpowiedź z wewnętrznego systemu zarządzania pakietami jest zgodna z protokołem Signed Exchange, ale odpowiedź z zewnętrznego interfejsu jest niezgodna, występuje prawdopodobnie błąd konfiguracji interfejsu.
  • Upewnij się, że używasz najnowszej wersji narzędzia AMP Packager.
  • Jeśli wykluczysz wszystkie powyższe przyczyny, możliwe, że błąd występuje w narzędziu AMP Packager. W takiej sytuacji zgłoś błąd.

URL ładunku wewnętrznego nie pasuje do adresu URL żądania w podpisanej komunikacji

Odpowiedź HTTP deklarowała zgodność z protokołem Signed Exchange, ale wartość jej parametru fallbackUrl była niezgodna z adresem URL żądania, a muszą one być identyczne co do bajta. Dlatego wyszukiwarka Google uzna, że odpowiedź nie pasuje do adresu URL żądania.

Wpływ na Twoją witrynę:

Jeśli strona ma odpowiednik inny niż AMP, wyszukiwarka Google w zamian go zindeksuje. W przeciwnym razie strona może się nie pojawić w wyszukiwarce Google.

Dalsze kroki:

Jeśli korzystasz z protokołu Signed Exchange udostępnianego przez dostawcę usług, poproś go o pomoc. Jedną z metod obejścia tego problemu jest zmiana adresu URL strony w celu uniknięcia błędów w popularnych parserach adresów URL. Spróbuj na początek wyeliminować znaki zakodowane za pomocą procentów lub zastrzeżone albo ciągi zapytań zakodowane w nietypowy sposób, np. przy użyciu znaków ? bez parametrów.

Jeśli korzystasz z narzędzia AMP Packager, ten błąd mógł wystąpić z kilku powodów:

  • Sprawdź, czy zwrotny serwer proxy interfejsu prawidłowo przepisuje adresy URL. Problemy mogą wystąpić zwłaszcza w przypadku adresów URL zawierających znaki zakodowane za pomocą procentów lub zastrzeżone. Na przykład serwer proxy nginx ma problemy z dyrektywą rewrite i z dyrektywą proxy_pass w postaci bez ścieżki. Aby to przetestować, wyślij kilka żądań testowych do interfejsu i porównaj je z adresami URL rejestrowanymi przez narzędzie AMP Packager w standardowym strumieniu wyjścia.
  • Upewnij się, że używasz najnowszej wersji narzędzia AMP Packager.
  • Jeśli wykluczysz wszystkie powyższe przyczyny, możliwe, że błąd występuje w narzędziu AMP Packager. W takiej sytuacji zgłoś błąd.

Nagłówek „header_name” odpowiedzi HTTP w podpisanej komunikacji zawiera nieprawidłową wartość

Odpowiedź HTTP zawierała nagłówek „content-type” application/signed-exchange, ale z jakiegoś powodu był on nieprawidłowy. Może np. brakowało w nim parametru v=b3. W efekcie Google nie może rozpoznać formatu odpowiedzi i wyodrębnić jej treści.

Wpływ na Twoją witrynę:

Jeśli strona ma odpowiednik inny niż AMP, wyszukiwarka Google w zamian go zindeksuje. W przeciwnym razie strona może się nie pojawić w wyszukiwarce Google.

Dalsze kroki:

Jeśli korzystasz z protokołu Signed Exchange udostępnianego przez dostawcę usług, poproś go o pomoc.

Jeśli korzystasz z narzędzia AMP Packager, ten błąd mógł wystąpić z kilku powodów:

  • Upewnij się, że zwrotny serwer proxy interfejsu nie zmienia nagłówków „content-type”. Aby wykryć błędny adres URL, sprawdź odpowiedni adres URL /priv/doc w domenie swojego wewnętrznego systemu zarządzania pakietami i pobierz ten adres razem z nagłówkami odpowiedzi (np. za pomocą polecenia curl -i). Jeśli nagłówki odpowiedzi z wewnętrznego systemu zarządzania pakietami różnią się od nagłówków odpowiedzi z zewnętrznego interfejsu, źródłem błędu mogą być właśnie te rozbieżności. Jeśli występują one w innym nagłówku niż „content-type”, zgłoś błąd w tym dokumencie pomocy, by umożliwić nam aktualizację listy wymagań.
  • Upewnij się, że używasz najnowszej wersji narzędzia AMP Packager.
  • Jeśli wykluczysz wszystkie powyższe przyczyny, możliwe, że błąd występuje w narzędziu AMP Packager. W takiej sytuacji zgłoś błąd.

Nadawanie priorytetów i naprawianie błędów

  1. Na stronie podsumowania AMP odfiltruj ostrzeżenia i skoncentruj się najpierw na błędach. Problemy są domyślnie posortowane według połączenia wagi błędu, stanu weryfikacji i liczby stron, których dotyczą. Zalecamy zajmowanie się nimi w tej kolejności domyślnej.Najpierw napraw błędy spowodowane częstymi przyczynami (np. niewłaściwym szablonem), a potem te, które są specyficzne dla poszczególnych stron.
  2. Sprawdź, czy któryś ze wzrostów całkowitej liczby błędów nie jest spowodowany głównie pojedynczym błędem – poszukaj w tabeli odpowiadającego mu gwałtownego skoku liczby błędów jednego rodzaju.
  3. Przeczytaj poniższe informacje o debugowaniu skoków i brakujących stron AMP.
  4. Kliknij wiersz w tabeli, by wyświetlić stronę ze szczegółowymi informacjami o błędzie:
    1. Strona z informacjami zawiera próbkę adresów URL stron, na których występuje dany błąd. Ta lista nie zawsze jest kompletna, ponieważ jest ograniczona do 1000 wierszy i może nie uwzględniać wykrytych ostatnio wystąpień błędu.
    2. Jeśli błąd jest błędem składniowym, kliknij Więcej informacji, by uzyskać oficjalną dokumentację dotyczącą prawidłowej składni.
    3. Kliknij ikonę inspekcji, by przeprowadzić test poprawności danej strony z błędem. Wyłapie on wszystkie błędy (nie tylko błąd bieżący) oraz wyświetli eksplorator kodu z wyróżnionymi błędami i dodatkowymi informacjami. Może się zdarzyć, że dany błąd został już naprawiony na działającej stronie, ale nadal widnieje na liście błędów, ponieważ strona nie została jeszcze zindeksowana ponownie. Jeśli tak jest, po naprawieniu wszystkich wystąpień tego błędu poproś o weryfikację strony.
  5. Napraw wszystkie wystąpienia błędu w witrynie, przetestuj poprawkę i upewnij się, że wprowadzone korekty działają w sieci.
  6. Wróć na stronę ze szczegółowymi informacjami o błędzie i kliknij przycisk Sprawdź poprawkę, by rozpocząć proces weryfikacji. Ten proces nie jest natychmiastowy.Aby dowiedzieć się o nim więcej, przeczytaj sekcję Informacje o weryfikowaniu.
  7. Napraw pozostałe błędy.
  8. Po naprawieniu wszystkich błędów usuń filtr ostrzeżeń i sprawdź, czy nie należy ich też wyeliminować. Niektóre ostrzeżenia dotyczą brakujących opcjonalnych znaczników uporządkowanych danych, które na stronach z odpowiednią treścią mogą włączyć nowe funkcje wyszukiwania.

Udostępnianie raportu

Możesz udostępnić szczegóły problemu z raportów dotyczących zasięgu lub ulepszeń, klikając przycisk Udostępnij  na stronie. Osoba, której udostępnisz link, będzie mieć dostęp tylko do bieżącej strony szczegółów problemu i wszystkich stron historii sprawdzania poprawności dotyczących tego problemu. Link nie zapewnia dostępu do innych stron witryny ani nie umożliwia tej osobie wykonywania żadnych czynności w Twojej usłudze lub na Twoim koncie. Link możesz w dowolnym momencie unieważnić, wyłączając udostępnianie tej strony.

Eksportowanie danych raportu

Wiele raportów ma przycisk eksportowania zawartych w nim danych . Eksportowane są dane z wykresu i tabeli.

Skoki liczby błędów

Sprawdź, czy skok liczby błędów nie został spowodowany przeniesieniem zbioru stron z jednej grupy wagi błędu do innej:

  1. Jeśli zauważysz gwałtowny wzrost, poszukaj odpowiadającego mu spadku innego stanu (błędnego lub prawidłowego).
  2. Jeśli znajdziesz taki spadek, sprawdź, czy dotyczy on tych samych adresów URL.
  3. Jeśli adresy URL zostały przeniesione z jednego stanu do innego, ustal, jaka czynność to spowodowała.

Najczęstszą przyczyną gwałtownych wzrostów liczby błędów jest wprowadzenie błędu do szablonu, z którego korzysta wiele stron w witrynie.

Rozwiązywanie problemów z brakującymi stronami AMP

Jeśli liczba stron AMP w raporcie (prawidłowych, z ostrzeżeniami i z błędami) jest mniejsza niż liczba stron AMP w witrynie, wypróbuj te rozwiązania:

  • Upewnij się, że kanoniczna strona inna niż AMP zawiera prawidłowy link do strony AMP.
  • Upewnij się, że strony kanoniczne lub AMP nie są wykluczone z indeksowania przez pliki robots.txt lub tagi noindex ani dostępne dopiero po uwierzytelnieniu lub zalogowaniu.
  • Sprawdź, czy strony kanoniczne i AMP znajdują się w indeksie. Aby to zrobić, wyszukaj w Google URL strony kanonicznej. Jeśli nie ma go na liście, strona nie została zindeksowana.
    • Jeśli wersja kanoniczna znajduje się na liście, upewnij się, że zawiera ona prawidłowe linki do strony AMP.
    • Jeśli wersji kanonicznej nie ma na liście, prześlij ją do zindeksowania.
  • Czy do strony AMP lub kanonicznej prowadzą linki z innych stron? Czy te strony są uwzględnione w mapie witryny? Aby poprosić o zindeksowanie niewielkiej liczby stron AMP, użyj narzędzia do sprawdzania adresów URL na stronie kanonicznej. Jeśli jednak chcesz zindeksować bardzo dużo stron, użyj mapy witryny. W mapie witryny musisz wskazać tylko stronę kanoniczną. Mapę witryny możesz przesłać w raporcie Mapy witryn.
  • W zależności od tego, w jaki sposób poinformujesz Google o nowych stronach, odszukanie i zindeksowanie brakujących stron może zająć kilka dni.
  • Niektóre prawidłowe strony AMP mogą nie zostać uwzględnione w tym raporcie, chociaż mogą być wymienione w raporcie Stan w indeksie. Wynika to z tego, że raport Stan w indeksie musi być bardziej kompleksowy, by ułatwić rozwiązywanie problemów z indeksowaniem wymienionych w raporcie. Raport „Stan stron AMP” może natomiast obejmować mniej stron, ale z większą trafnością i szczegółowością, by umożliwić rozwiązywanie konkretnych problemów ze stronami AMP w witrynie. Aby sprawdzić, czy strona AMP jest zindeksowana, użyj narzędzia do sprawdzania adresów URL – wyświetli ono jednoznaczną odpowiedź.

Znaczenie ostrzeżeń

Strony AMP z ostrzeżeniami są indeksowane i mogą pojawiać się w wynikach wyszukiwania Google, ale w przypadku takich stron niektóre funkcje AMP mogą nie być obsługiwane (na przykład strony mogą nie pokazywać się w karuzeli Najważniejsze artykuły). Czyli może się okazać, że te strony wyświetlają się w wynikach wyszukiwania tylko jako zwykłe niebieskie linki.

Informacje o weryfikacji

Po naprawieniu wszystkich wystąpień określonego problemu w witrynie możesz poprosić Google o zweryfikowanie zmian. Jeśli wszystkie znane wystąpienia znikną, problem zostanie oznaczony w tabeli stanów jako rozwiązany i umieszczony na dole. Search Console śledzi stan weryfikacji całego problemu, a także stan każdego jego wystąpienia. Po zniknięciu wszystkich wystąpień problem uznaje się za rozwiązany. (Informacje o rejestrowaniu stanów faktycznych – patrz: Stan weryfikacji problemuStan weryfikacji wystąpienia).

Więcej informacji o czasie trwania problemu

Czas trwania problemu to okres od pierwszego dnia, gdy wykryto jakiekolwiek wystąpienie tego problemu w Twojej witrynie, aż do 90 dni po zniknięciu z witryny ostatniego wystąpienia. Gdy minie 90 dni bez żadnych powtórzeń, problem jest usuwany z historii zgłoszeń.

Data pierwszego wykrycia problemu to moment, w którym problem został po raz pierwszy wykryty. Ta data jest niezmienna. Dlatego:

  • Jeśli wszystkie wystąpienia problemu zostaną naprawione, ale 15 dni później pojawi się nowe wystąpienie, problem zostanie oznaczony jako otwarty, ale datą „pierwszego wykrycia” pozostanie data pierwotna.
  • Jeśli ten sam problem wystąpi 91 dni po naprawieniu ostatniego wystąpienia, poprzedni problem będzie już zamknięty, więc obecne wystąpienie zostanie zarejestrowane jako nowy problem z datą pierwszego wykrycia ustawioną na „dzisiaj”.

Podstawowy proces weryfikacji

Oto omówienie procesu weryfikacji, który następuje po kliknięciu opcji Sprawdź poprawkę danego problemu. Proces może potrwać kilka dni. W tym czasie będziesz otrzymywać e-maile z powiadomieniami o postępach.

  1. Gdy klikniesz Sprawdź poprawkę, Search Console od razu sprawdza kilka stron.
    • Jeśli na dowolnej z tych stron znajdzie bieżące wystąpienie, weryfikacja kończy się, a jej stan się nie zmienia.
    • Jeśli na przykładowych stronach nie ma tego błędu, weryfikacja przechodzi do etapu Rozpoczęta. Jeśli weryfikacja wykaże inne, niepowiązane problemy, zostają one policzone jako problemy odpowiedniego typu i proces weryfikacji jest kontynuowany.
  2. Search Console sprawdza listę znanych adresów URL, których dotyczy dany problem. W kolejce do ponownego zindeksowania ustawiane są tylko adresy URL ze znanymi wystąpieniami problemu, a nie cała witryna. Search Console prowadzi rejestr wszystkich sprawdzonych adresów URL w historii weryfikacji, do której można przejść ze strony szczegółów problemu.
  3. Podczas sprawdzania adresu URL:
    1. Jeśli problem nie zostanie znaleziony, stan weryfikacji wystąpienia zmienia się na Powodzenie. Jeśli jest to pierwsze wystąpienie sprawdzone po rozpoczęciu weryfikacji, stan weryfikacji wystąpienia zmienia się na Wszystko w porządku.
    2. Jeśli adres URL jest już niedostępny, stan weryfikacji wystąpienia zmienia się na Inne (nie jest to stan błędu).
    3. Jeśli wystąpienie nadal jest obecne, stan problemu zmienia się na Niepowodzenie i weryfikacja się kończy. Jeśli jest to nowa strona wykryta podczas standardowego indeksowania, stwierdza się kolejne wystąpienie istniejącego problemu.
  4. Jeśli po sprawdzeniu wszystkich adresów URL z błędami i ostrzeżeniami liczba problemów wynosi 0, stan problemu zmienia się na Powodzenie. Ważne: nawet jeśli liczba stron, których dotyczy problem, spadnie do zera, a stan problemu zmieni się na Powodzenie, pierwotna etykieta wagi (Błąd lub Ostrzeżenie) będzie nadal widoczna.

Nawet jeśli nie klikniesz przycisku „Rozpocznij weryfikację”, Google może wykryć naprawione wystąpienia problemu. Jeśli podczas standardowego indeksowania Google wykryje, że wszystkie wystąpienia problemu zostały naprawione, stan problemu zmieni się w raporcie na „Nie dotyczy”.

Kiedy problem związany z adresem URL lub elementem jest uznawany za „rozwiązany”?

W przypadku adresu URL lub elementu problem jest oznaczany jako rozwiązany, gdy spełniony jest dowolny z tych warunków:

  • Adres URL został zindeksowany i na stronie nie wykryto już problemu. W przypadku błędu tagu AMP może to oznaczać, że tag został albo naprawiony, albo usunięty (jeśli nie jest wymagany). Próba weryfikacji da wówczas wynik „Powodzenie”.
  • Jeśli z jakiegokolwiek powodu strona będzie niedostępna dla Google (np. została usunięta lub oznaczona jako noindex, wymaga uwierzytelnienia itd.), problem dotyczący tego adresu URL zostanie uznany za rozwiązany. Przy próbie weryfikacji przypisany zostanie stan „Inne”.

Ponowna weryfikacja

Jeśli po nieudanej weryfikacji klikniesz Zweryfikuj ponownie, rozpocznie się ponowna weryfikacja wszystkich wystąpień z wynikiem Niepowodzenie oraz wszelkich nowych wystąpień problemu wykrytych podczas standardowego indeksowania.

Nawet jeśli w czasie trwania danego cyklu weryfikacji rozwiążesz jakiś problem, poczekaj na zakończenie cyklu, zanim poprosisz o rozpoczęcie kolejnego.

Wystąpienia, które pomyślnie przeszły weryfikację (zostały oznaczone jako Powodzenie) albo są już nieosiągalne (zostały oznaczone jako Inne), nie są sprawdzane ponownie. Po kliknięciu „Zweryfikuj ponownie” są usuwane z historii.

Historia weryfikacji

Postęp w realizacji prośby o weryfikację możesz sprawdzić, klikając link szczegółów weryfikacji na stronie szczegółów problemu.

Wpisy w historii weryfikacji są pogrupowane według adresów URL na potrzeby raportu AMP i raportu stanu indeksowania. Elementy w raportach dotyczących obsługi na urządzeniach mobilnych i wyników z elementami rozszerzonymi są pogrupowane według kombinacji adres URL + element uporządkowanych danych (zgodnie z wartością nazwy elementu). Stan weryfikacji odnosi się do konkretnego sprawdzanego problemu. Jeden problem może mieć na stronie etykietę „Powodzenie”, a inne mogą być oznaczone etykietą „Niepowodzenie”, „Oczekuje” lub „Inne”.

Stan weryfikacji problemu

Do problemu mogą zostać przypisane te stany weryfikacji:

  • Nie rozpoczęto: istnieje co najmniej jedna strona z wystąpieniem tego problemu, dla której nigdy nie podjęto próby weryfikacji. Dalsze kroki
    1. Kliknij problem, by zapoznać się ze szczegółami błędu. Sprawdź poszczególne strony, by zobaczyć przykłady błędu na aktywnej stronie, korzystając z testu AMP. (Jeśli test AMP nie pokazuje błędu na stronie, jest to spowodowane tym, że błąd został naprawiony na aktywnej stronie już po wykryciu go przez Google i wygenerowaniu raportu o problemie).
    2. Kliknij „Więcej informacji” na stronie szczegółów, by zobaczyć szczegóły naruszonej reguły.
    3. Kliknij wiersz przykładowego adresu URL w tabeli, by zobaczyć szczegóły konkretnego błędu.
    4. Napraw błędy na swoich stronach, a następnie kliknij Sprawdź poprawkę, a Google ponownie zindeksuje Twoje strony. Google powiadomi Cię o postępach weryfikacji. Weryfikacja trwa od kilku dni do około dwóch tygodni – prosimy o cierpliwość. 
  • Rozpoczęto: rozpoczęto próbę weryfikacji i do tej pory nie znaleziono pozostałych wystąpień problemu. Dalsze kroki: w miarę postępów weryfikacji Google będzie wysyłać powiadomienia z informacjami o ewentualnej konieczności podjęcia jakichś działań.
  • Wszystko w porządku: rozpoczęto próbę weryfikacji i do tej pory wszystkie sprawdzone wystąpienia problemu zostały naprawione. Dalsze kroki: nie musisz nic robić; w miarę postępów weryfikacji Google będzie wysyłać powiadomienia z informacjami o ewentualnej konieczności podjęcia jakichś działań.
  • Powodzenie: wszystkie znane wystąpienia problemu zostały zlikwidowane (lub adres URL, którego dotyczył problem, jest już niedostępny). Przejście do tego stanu wymaga wcześniejszego kliknięcia opcji „Sprawdź poprawkę” (jeśli wystąpienia znikną bez zgłaszania prośby o weryfikację, stan zmieni się na „Nie dotyczy”). Dalsze kroki: nie musisz nic robić.
  • Nie dotyczy: Google uznaje problem za rozwiązany dla wszystkich adresów URL, nawet jeśli nigdy nie rozpoczęto próby weryfikacji. Dalsze kroki: nie musisz nic robić.
  • Niepowodzenie: po kliknięciu „Zweryfikuj” na określonej liczbie stron nadal występuje problem. Dalsze kroki: rozwiąż problem i przeprowadź ponowną weryfikację.

Stan weryfikacji wystąpienia

Po przesłaniu prośby o weryfikację każdemu wystąpieniu problemu jest przypisywany jeden z poniższych stanów weryfikacji:

  • Oczekuje na weryfikację: w kolejce do zweryfikowania. Podczas ostatniej kontroli Google wystąpienie problemu nadal istniało.
  • Powodzenie: [Niedostępne w niektórych raportach] kontrola Google wykazała, że to wystąpienie problemu nie istnieje. Do tego stanu można przejść wyłącznie przez celowe kliknięcie opcji Zweryfikuj dla danego wystąpienia problemu.
  • Niepowodzenie: kontrola Google wykazała, że dane wystąpienie problemu nie zniknęło. Do tego stanu można przejść wyłącznie przez celowe kliknięcie opcji Zweryfikuj dla danego wystąpienia problemu.
  • Inne: [Niedostępne w niektórych raportach] Google nie ma dostępu do adresu URL powiązanego z danym wystąpieniem albo (w przypadku uporządkowanych danych) nie może już znaleźć elementu na stronie. Jest to równoznaczne ze stanem Powodzenie.

Pamiętaj, że ten sam URL może mieć różne stany dla różnych problemów. Jeśli na przykład jedna strona zawiera zarówno problem X, jak i Y, problem X może mieć stan weryfikacji Powodzenie, a problem Y na tej samej stronie – stan Oczekuje.

 

Znane problemy

Oto znane problemy w Search Console. Nie musisz ich nam zgłaszać, ale chętnie poznamy Twoją opinię o wszystkich pozostałych funkcjach lub zauważonych problemach. Aby ją przesłać, użyj funkcji dodawania opinii na pasku nawigacyjnym.

  • Niektóre problemy mają długie nazwy, które niełatwo zrozumieć.
  • Między dodaniem problemu do wykresu a pojawieniem się go w tabeli może występować opóźnienie.
  • Jeśli w witrynie występuje bardzo dużo błędów (niezależnie od tego, czy są one aktywne), raport pokazuje tylko pierwsze 200 z nich. Są one ułożone według stopnia ważności.
Czy to było pomocne?
Jak możemy ją poprawić?