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 obsługujących funkcje związane z AMP.

Widok główny zawiera problemy krytyczne, wpływające na strony AMP w witrynie. Kliknij konkretny błąd, aby wyświetlić strony, na których występuje, oraz szczegółowe informacje na jego temat.

OTWÓRZ RAPORT O STRONACH AMP

 

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

 

Co zawiera ten raport

Problemy krytyczne: strony z problemami krytycznymi związanymi z AMP nie mogą być wyświetlane w Google. Lista problemów krytycznych w witrynie znajduje się bezpośrednio pod wykresem na stronie głównej raportu AMP, w tabeli Dlaczego strony AMP są nieprawidłowe. Kliknij problem na liście, aby wyświetlić strony, na których występuje.

Problemy niekrytyczne (ostrzeżenia): strony AMP z problemami niekrytycznymi mogą być nadal widoczne w Google, o ile nie zawierają żadnych problemów krytycznych. Lista problemów niekrytycznych w witrynie znajduje się pod listą problemów krytycznych na stronie głównej raportu AMP, w tabeli Problemy niekrytyczne. Kliknij problem na liście, aby wyświetlić strony, na których występuje. W przypadku stron AMP z ostrzeżeniami 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.

Stan strony (strony prawidłowe i nieprawidłowe): strony AMP mogą być prawidłowe lub nieprawidłowe. Prawidłowe strony AMP mogą być wyświetlane w Google, a nieprawidłowe – nie. Jeśli strona zawiera problemy krytyczne, zostaje uznana za nieprawidłową; jeśli ma tylko ostrzeżenia lub nie zawiera żadnych problemów, jest uznawana za prawidłową. Aby wyświetlić listę prawidłowych stron AMP, kliknij Wyświetl dane na temat prawidłowych stron AMP pod wykresem na stronie głównej raportu AMP.

Na co zwrócić uwagę

Raport powinien zawierać te wartości:

Lista adresów URL, których dotyczy problem, nie jest wyczerpująca – niektóre adresy URL, w przypadku których dany problem występuje, mogą być niewidoczne. Raport może zawierać maksymalnie 1000 adresów URL na problem. Poza tym mogą jeszcze istnieć inne strony, których nie wykryliśmy lub których z jakiegoś powodu nie uwzględniliśmy.

Raport może zawierać maksymalnie 200 problemów krytycznych i niekrytycznych. Jeśli w witrynie występuje bardzo długa lista problemów (niezależnie od tego, czy są one aktywne), raport pokazuje tylko 200 najczęstszych z nich, uporządkowanych według ważności.

Błędy AMP

Oprócz standardowych błędów AMP raport może wskazywać dodatkowe problemy (błędy i ostrzeżenia) 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ą 2 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ą inną 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. Jeśli jest to niezgodne z Twoimi oczekiwaniami, przetestuj plik robots.txt pod kątem reguły blokowania, a następnie zmodyfikuj lub usuń regułę (albo poproś o to dewelopera).
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 dyrektywy „noindex”. Google nie może indeksować takich stron. Usuń dyrektywę „noindex” lub usuń odniesienie do blokowanej strony.
Minął termin „unavailable_after” dla tej strony W przypadku strony AMP istnieje metatag lub dyrektywa „unavailable_after” z datą w przeszłości, co wskazuje, że strony nie należy wyświetlać. Zaktualizuj tag, aby 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.
Zadeklarowano skrypt modułu bez alternatywy dla braku modułu (lub odwrotnie) Używasz tagu <script type="module"> bez pasującego tagu <script nomodule async> (lub odwrotnie). Tych tagów należy używać parami, aby umożliwić ich prawidłową obsługę w przeglądarkach, które mogą lub nie mogą korzystać ze skryptów modułów.
Brak adresu URL w tagu HTML Wskazany tag HTML wymaga atrybutu z prawidłowym adresem URL o niezerowej długości, ale podany URL to pusty ciąg znaków. Podaj prawidłowy adres URL wyróżnionego atrybutu.
Brak atrybutu lub jest on nieprawidłowy, choć jest wymagany przez atrybut „on” Wskazany atrybut jest wymagany, ale nie został podany lub jest nieprawidłowy. Ten atrybut jest wymagany, ponieważ w tym samym tagu określono atrybut „on”.
Znaleziono tag podrzędny <svg> na zewnątrz bloku <svg> Poza blokiem <svg> określono tag, który musi być zagnieżdżony w bloku <svg>.
Ta strona wczytuje kilka wersji skryptu tego samego rozszerzenia Strona wczytuje kilka wersji tego samego rozszerzenia do stron AMP. Aby naprawić ten błąd, usuń jedną wersję skryptu.
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 technologią Signed Exchange

Informacje o technologii Signed Exchange powiązanej 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 technologii 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, aby zbadać konkretny adres URL, albo w raporcie o stanie stron AMP kliknij ikonę inspekcji  obok adresu URL w tabeli szczegółów problemu).
  2. Na stronie wyników kliknij Wyświetl zindeksowaną stronę, aby 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 technologii Signed Exchange mogą wystąpić takie błędy:

Podpisana komunikacja jest nieprawidłowa

Odpowiedź HTTP deklarowała zgodność z technologią 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 adresem URL źródła.

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 technologii Signed Exchange udostępnianej 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 adresem URL źródła.

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, aby ta strona otwierała się z jej podpisanym adresem URL, czytaj dalej.

Aby znaleźć i naprawić błąd, wykonaj te czynności:

  • 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 technologią 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 adresem URL źródła.

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, aby ta strona otwierała się z jej podpisanym adresem URL, czytaj dalej.

Jeśli korzystasz z technologii Signed Exchange udostępnianej 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 adresem URL źródła.

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, aby ta strona otwierała się z jej podpisanym adresem URL, czytaj dalej.

Jeśli korzystasz z technologii Signed Exchange udostępnianej 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 technologią Signed Exchange, ale zawierała nagłówek podpisu niezgodny ze specyfikacją tej technologii. 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 adresem URL źródła.

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, aby ta strona otwierała się z jej podpisanym adresem URL, czytaj dalej.

Jeśli korzystasz z technologii Signed Exchange udostępnianej 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 adresem URL źródła.

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, aby ta strona otwierała się z jej podpisanym adresem URL, czytaj dalej.

Jeśli korzystasz z technologii Signed Exchange udostępnianej 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 technologią Signed Exchange, ale nagłówek podpisu zawierał wartość parametru date lub expires, która nie spełniała wymagań tej technologii 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 adresem URL źródła.

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, aby ta strona otwierała się z jej podpisanym adresem URL, czytaj dalej.

Jeśli korzystasz z technologii Signed Exchange udostępnianej 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 adresem URL źródła.

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, aby ta strona otwierała się z jej podpisanym adresem URL, czytaj dalej.

Jeśli korzystasz z technologii Signed Exchange udostępnianej 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 technologią Signed Exchange, ale zawierała wartość parametru „cert-url” nieprawidłową w świetle specyfikacji tej technologii. 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 adresem URL źródła.

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, aby ta strona otwierała się z jej podpisanym adresem URL, czytaj dalej.

Jeśli korzystasz z technologii Signed Exchange udostępnianej 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 technologii Signed Exchange udostępnianej 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 technologii Signed Exchange udostępnianej 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. Spójrz na listę problemów krytycznych w witrynie (znajdziesz ją w tabeli Dlaczego strony AMP są nieprawidłowe).
  2. Przeanalizuj problemy:
    • 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 typu.
    • Najpierw napraw błędy spowodowane częstymi przyczynami (na przykład niewłaściwym szablonem), a następnie te, które są specyficzne dla poszczególnych stron.
  3. Napraw znalezione błędy. Kliknij wiersz w tabeli, aby wyświetlić stronę ze szczegółowymi informacjami o danym błędzie:
    1. Strona z informacjami zawiera próbkę adresów URL stron, na których dany błąd występuje. Lista jest ograniczona do 1000 wierszy i może nie uwzględniać ostatnio wykrytych wystąpień błędu lub stron, które nie zostały ponownie zindeksowane od czasu wystąpienia błędu.
    2. Obok problemu kliknij Więcej informacji, aby wyświetlić oficjalną dokumentację dotyczącą tego błędu.
    3. Kliknij adres URL w tabeli z przykładowymi adresami URL, aby zobaczyć problem wyróżniony w kodzie strony.
    4. Kliknij ikonę inspekcji , aby przeprowadzić szczegółowy test danej strony. 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. Jeśli strona nie została ostatnio zindeksowana ponownie, zobaczysz problem związany ze zindeksowaną stroną, a nie stroną aktywną. W takim przypadku możesz poprosić o zindeksowanie danej strony.
    5. Napraw wszystkie wystąpienia błędu w witrynie, przetestuj poprawkę i upewnij się, że wprowadzone poprawki działają w sieci.
  4. Po naprawieniu wszystkich wystąpień błędu wróć na stronę ze szczegółowymi informacjami o błędzie i kliknij przycisk Sprawdź poprawkę, aby rozpocząć proces weryfikacji. Ten proces nie jest natychmiastowy. Aby dowiedzieć się o nim więcej, przeczytaj informacje o weryfikowaniu.
  5. Napraw pozostałe błędy.
  6. Jeśli łączna liczba prawidłowych i nieprawidłowych stron jest znacznie mniejsza niż liczba stron AMP w witrynie, zapoznaj się z sekcją Rozwiązywanie problemów z brakującymi stronami AMP.
  7. Gdy rozwiążesz wszystkie problemy krytyczne, spróbuj rozwiązać te niekrytyczne. Niektóre problemy niekrytyczne (np. korzystanie z wycofanych funkcji) mogą w przyszłości stać się krytyczne.

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.Wartości pokazane w raporcie jako ~ lub – (niedostępna / nie jest liczbą) będą po pobraniu równe 0.

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

Jeśli liczba stron AMP (prawidłowych i nieprawidłowych) w raporcie 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 zalogowaniu.
  • Sprawdź adres URL strony kanonicznej, aby zobaczyć, czy 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.
  • 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 Indeksowanie stron. Wynika to z tego, że raport Indeksowanie stron musi być bardziej kompleksowy, aby ułatwiał rozwiązywanie wymienionych problemów z indeksowaniem. Z kolei raport o stanie stron AMP może obejmować mniej stron, jednak wybranych z większą trafnością i przedstawionych bardziej szczegółowo, aby umożliwiał 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ź.
Przesyłanie poprawek do weryfikacji

Po naprawieniu wszystkich wystąpień określonego problemu w witrynie możesz poprosić Google o potwierdzenie poprawek. Jeśli wszystkie znane wystąpienia znikną, liczba problemów w tabeli problemów będzie wynosić 0, a problem znajdzie się na jej dole.

Cele weryfikacji

Oto zalety poinformowania Google o usunięciu wszystkich problemów o określonym stanie lub kategorii:

  • Otrzymasz e-maila, gdy potwierdzimy rozwiązanie problemu we wszystkich adresach URL lub odwrotnie – jeśli znajdziemy pozostałe wystąpienia tego problemu.
  • Możesz śledzić postępy Google w potwierdzaniu poprawek, przeglądać log wszystkich stron znajdujących się w kolejce do sprawdzenia oraz sprawdzać stan poprawek każdego adresu URL.

Naprawianie i weryfikowanie konkretnego problemu w witrynie nie zawsze ma sens: na przykład adresy URL zablokowane przez plik robots.txt są prawdopodobnie blokowane celowo. Decydując o tym, czy rozwiązać dany problem, należy kierować się zdrowym rozsądkiem.

Możesz też rozwiązywać problemy bez weryfikacji poprawek. Google aktualizuje liczbę wystąpień za każdym razem, gdy indeksuje stronę ze znanymi problemami, niezależnie od tego, czy wyraźnie poprosisz o weryfikację.

Wskazówka: zweryfikuj poprawki z wykorzystaniem mapy witryny
Aby przyspieszyć prośbę o weryfikację poprawek, utwórz i prześlij mapę witryny zawierającą tylko najważniejsze strony. Następnie, zanim poprosisz o weryfikację, przefiltruj raport według tej mapy. Prośba o weryfikację podzbioru adresów URL, których dotyczy problem, może zostać zrealizowana szybciej niż prośba obejmująca wszystkie problematyczne adresy URL w Twojej witrynie.

Rozpoczęcie weryfikacji

Aby poinformować Search Console o rozwiązaniu problemu:

  1. Napraw wszystkie wystąpienia problemu w witrynie. Jeśli nie udało Ci się rozwiązać problemu, weryfikacja zostanie zatrzymana, gdy Google znajdzie co najmniej 1 pozostałe jego wystąpienie.
  2. Otwórz stronę z informacjami o rozwiązanym problemie. Kliknij problem na liście problemów w raporcie.
    • ⚠️ Jeśli raport jest filtrowany według konkretnej mapy witryny, weryfikacja obejmuje tylko elementy w tej mapie w momencie przesłania prośby o weryfikację. Być może nie o to Ci chodzi, dlatego pamiętaj o tym.
  3. Kliknij Sprawdź poprawkę. Nie klikaj ponownie tego przycisku, dopóki weryfikacja nie zakończy się powodzeniem lub niepowodzeniem. Dowiedz się więcej o tym, jak Google sprawdza Twoje poprawki.
  4. Możesz śledzić postęp weryfikacji. Weryfikacja zajmuje zazwyczaj do 2 tygodni, ale w niektórych przypadkach może potrwać znacznie dłużej, dlatego zachowaj cierpliwość. Otrzymasz powiadomienie o powodzeniu lub niepowodzeniu weryfikacji.
  5. Jeśli weryfikacja zakończy się niepowodzeniem, możesz sprawdzić, który adres URL się do tego przyczynił. W tym celu na stronie z informacjami o problemie kliknij Sprawdź szczegóły. Rozwiąż problemy na wybranej stronie, potwierdź poprawkę w przypadku wszystkich adresów URL o stanie Oczekuje i ponownie uruchom weryfikację.

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

W przypadku adresu URL lub innego 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 daje 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.

Czas 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 tabeli problemów.

Data pierwszego wykrycia problemu to moment, w którym problem został wykryty po raz pierwszy. 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 nową datą pierwszego wykrycia.
Proces weryfikacji

Oto jak przebiega proces weryfikacji, który następuje po kliknięciu opcji Sprawdź poprawkę obok danego problemu. Proces ten może potrwać kilka dni lub dłużej. 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 danego błędu, weryfikacja przechodzi w stan Rozpoczęto. Jeśli weryfikacja wykaże inne, niepowiązane problemy, są one zaliczane do problemów 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 z informacjami o problemie.
  3. Podczas sprawdzania adresu URL:
    1. Jeśli problem nie zostanie znaleziony, stan weryfikacji wystąpienia zmieni się na Brak naruszeń. Jeśli jest to pierwsze wystąpienie sprawdzone po rozpoczęciu weryfikacji, stan weryfikacji problemu 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 dotychczasowego problemu.
  4. Gdy po sprawdzeniu adresów URL w kolejce okaże się, że problem został rozwiązany, stan problemu zmieni się na Powodzenie. Nawet jeśli wszystkie wystąpienia zostaną naprawione, pierwotna etykieta wagi problemu będzie nadal widoczna (Błąd lub Ostrzeżenie). Zmieni się jedynie liczba elementów, których dotyczy problem (0).

Nawet jeśli nie klikniesz przycisku rozpoczęcia weryfikacji, Google może wykryć naprawione wystąpienia problemu. Jeśli podczas standardowego indeksowania Google wykryje, że wszystkie wystąpienia problemu zostały naprawione, liczba problemów w raporcie zmieni się na 0.

Ponowna weryfikacja

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

Aby ponownie uruchomić weryfikację, która zakończyła się niepowodzeniem:

  1. Przejdź do dziennika weryfikacji zakończonej niepowodzeniem: otwórz stronę z informacjami o problemie, który nie przeszedł weryfikacji, i kliknij Sprawdź szczegóły.
  2. Kliknij Rozpocznij nową weryfikację.
  3. Weryfikacja zostanie ponownie uruchomiona w przypadku wszystkich adresów URL oznaczonych jako Oczekuje lub Niepowodzenie, a także w przypadku wszystkich nowych wystąpień tego problemu wykrytych podczas standardowego indeksowania od ostatniej próby weryfikacji. Adresy URL oznaczone jako Powodzenie i Inne nie są sprawdzane ponownie.
  4. Weryfikacja zajmuje zazwyczaj do 2 tygodni, ale w niektórych przypadkach może potrwać znacznie dłużej, dlatego zachowaj cierpliwość.

Sprawdzanie postępu weryfikacji

Aby sprawdzić postęp bieżącej prośby o weryfikację lub historię ostatniej prośby, jeśli weryfikacja nie jest w toku:

  1. Otwórz stronę z informacjami o problemie. Na głównej stronie raportu kliknij wiersz problemu, aby otworzyć stronę z informacjami.
    • Stan prośby o weryfikację jest wyświetlany zarówno na stronie z informacjami o problemie, jak i w tabeli ze szczegółami, w wierszu Weryfikacja.
  2. Kliknij Sprawdź szczegóły, aby otworzyć stronę z informacjami o weryfikacji, której dotyczy dana prośba.
    • Stan wystąpienia w przypadku każdego adresu URL uwzględnionego w prośbie jest podany w tabeli.
    • Stan wystąpienia 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.
    • W raporcie o stanie stron AMP i raporcie Indeksowanie stron wpisy na stronie historii weryfikacji są pogrupowane według adresu URL.
    • Elementy w raportach dotyczących obsługi na urządzeniach mobilnych i stanu wyników z elementami rozszerzonymi są pogrupowane według kombinacji adres URL + element uporządkowanych danych (zgodnie z wartością nazwy elementu).
Stan prośby o weryfikację

Do problemu mogą zostać przypisane te stany weryfikacji:

  • Nie rozpoczęto: co najmniej jedno wystąpienie danego problemu nigdy nie było uwzględnione w prośbie o weryfikację.
    Dalsze kroki:
    1. Kliknij problem, aby zapoznać się ze szczegółami błędu. Sprawdź poszczególne strony, aby zobaczyć przykłady błędu na aktywnej stronie.
    2. Aby dowiedzieć się więcej o problemie, na stronie szczegółów kliknij Więcej informacji.
    3. Kliknij wiersz przykładowego adresu URL w tabeli, aby zobaczyć szczegóły konkretnego błędu.
    4. Napraw błędy na stronach, a następnie kliknij Sprawdź poprawkę, aby rozpocząć weryfikację. Weryfikacja zajmuje zazwyczaj do 2 tygodni, ale w niektórych przypadkach może potrwać znacznie dłużej, dlatego zachowaj 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 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 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 ponownie uruchom 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: 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 już 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. Na przykład, jeśli 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.

Czy to było pomocne?

Jak możemy ją poprawić?

Potrzebujesz dodatkowej pomocy?

Wykonaj te czynności:

Zadaj pytanie na forum pomocy Uzyskaj odpowiedzi od członków społeczności
true
Nowy użytkownik Search Console?

Nie znasz jeszcze Search Console? Niezależnie od tego, czy jesteś początkującym użytkownikiem, ekspertem od SEO czy deweloperem stron internetowych, zacznij tutaj.

Szukaj
Wyczyść wyszukiwanie
Zamknij wyszukiwanie
Menu główne
17101483411772106989
true
Wyszukaj w Centrum pomocy
true
true
true
true
true
83844
false
false