Weryfikacja Search Console plikiem HTML. Co zrobić, gdy Google go nie widzi?

Plik weryfikacyjny został wgrany na serwer, przycisk „Zweryfikuj” kliknięty, a Search Console odpowiada, że pliku nie znaleziono. To jedna z najczęstszych przeszkód na samym początku pracy z narzędziem Google i zarazem jedna z najbardziej irytujących, bo właściciel strony jest przekonany, że wszystko zrobił zgodnie z instrukcją.

Ten wpis jest przeznaczony dla osób, które prowadzą firmę i samodzielnie dodają swoją stronę do Search Console albo robią to z pomocą informatyka lub firmy hostingowej. Nie wymaga wiedzy programistycznej, wystarczy dostęp do plików strony i do konta Google.

Po lekturze będzie wiadomo, jak rozpoznać, który z kilku możliwych powodów zachodzi w danym przypadku, jak sprawdzić to samodzielnie w przeglądarce, jak naprawić każdą z przyczyn i jak upewnić się, że weryfikacja nie przepadnie po kilku tygodniach.

Po czym poznać, że Search Console nie znalazła pliku?

Po kliknięciu „Zweryfikuj” Search Console od razu próbuje pobrać plik ze strony. Jeśli się to nie uda, w oknie weryfikacji pojawia się komunikat o niepowodzeniu wraz z krótkim opisem powodu. Ten opis jest najważniejszą wskazówką, dlatego przed zamknięciem okna trzeba go przeczytać w całości, a najlepiej przepisać lub zachować w postaci zrzutu ekranu.

Pomoc Google wymienia cztery błędy właściwe dla tej metody. Pierwszy to „W żądanej lokalizacji nie znaleziono Twojego pliku weryfikacyjnego”, czyli pod adresem, pod którym Google szuka pliku, nie ma nic albo jest coś innego. Drugi to „Zawartość Twojego pliku weryfikacyjnego jest nieprawidłowa”, czyli plik istnieje, ale jego treść różni się od wydanej przez Search Console. Trzeci dotyczy przekierowania do niedozwolonej lokalizacji, a czwarty podejrzenia, że strona padła ofiarą włamania.

Obok nich istnieje grupa błędów ogólnych, wspólnych dla wszystkich metod: upłynięcie limitu czasu połączenia z serwerem, błąd przy sprawdzaniu nazwy domeny, zbyt wiele przekierowań, nieprawidłowa odpowiedź serwera albo brak możliwości połączenia. One wskazują nie na sam plik, lecz na serwer lub domenę.

Zdarza się też inna odmiana problemu: weryfikacja kiedyś się powiodła, a po pewnym czasie przychodzi wiadomość, że Google nie może już potwierdzić własności. Przyczyny są te same, tylko pojawiły się później, najczęściej po zmianie hostingu, przebudowie strony albo porządkach na serwerze.

Jakie warunki musi spełniać plik, żeby Google go zaakceptował?

Zanim zacznie się szukać usterki, dobrze jest znać zasady, według których Google ocenia plik. Jest ich niewiele, ale każda jest bezwzględna.

• Plik musi być dostępny dla osoby niezalogowanej. Nie może go chronić hasło, okno logowania ani tryb „strona w budowie”.
• Plik musi leżeć w katalogu głównym usługi, czyli otwierać się pod adresem złożonym z adresu usługi i nazwy pliku, bez żadnych podkatalogów pośrednich.
• Nazwa i zawartość pliku muszą pozostać dokładnie takie, jak w pliku pobranym z Search Console. Dozwolone jest jedynie dopisanie nowych wierszy na końcu.
• Metoda działa wyłącznie dla usługi z prefiksem URL. Usługi domeny nie da się zweryfikować plikiem, do tego służy tylko rekord DNS.
• Plik jest przypisany do jednego konta Google. Plik pobrany przez inną osobę nie potwierdzi własności na koncie właściciela firmy.

Przykład pomaga to sobie wyobrazić. Jeśli usługa została dodana jako https://www.przyklad.pl/, a pobrany plik nazywa się google0a1b2c3d4e5f6a7b.html, to Google zajrzy dokładnie pod adres https://www.przyklad.pl/google0a1b2c3d4e5f6a7b.html i nigdzie indziej.

Z tych zasad wynika prosty wniosek: prawie każda nieudana weryfikacja sprowadza się do jednego z czterech pytań. Czy plik jest we właściwym miejscu? Czy adres usługi jest tym samym adresem, pod którym działa strona? Czy plik nie został zmieniony? Czy serwer wpuszcza do niego kogoś z zewnątrz?

Jak w kilka minut sprawdzić, co naprawdę widzi Google?

Najpewniejszy test nie wymaga żadnych narzędzi poza przeglądarką. Chodzi o to, żeby spojrzeć na plik oczami osoby z zewnątrz, a nie właściciela zalogowanego do panelu strony.

1. W Search Console należy otworzyć okno weryfikacji usługi i rozwinąć metodę z plikiem HTML. Widoczna jest tam nazwa pliku do pobrania.
2. Trzeba zestawić pełny adres: adres usługi widoczny u góry okna weryfikacji, a zaraz po nim nazwa pliku. Adres usługi należy przepisać co do znaku, razem z początkiem http:// lub https:// oraz z przedrostkiem www albo bez niego.
3. W przeglądarce otwiera się okno incognito (prywatne). W takim oknie nie działa zalogowanie do panelu strony, więc widok jest taki sam jak dla obcej osoby.
4. Zestawiony adres wkleja się w pasek adresu i zatwierdza klawiszem Enter.
5. Należy przeczytać, co się wyświetliło, i spojrzeć ponownie na pasek adresu, czy adres po załadowaniu jest nadal taki sam, jak wklejony.

Prawidłowy wynik to niemal pusta, biała strona z jednym wierszem tekstu w postaci:

google-site-verification: google0a1b2c3d4e5f6a7b.html

Nazwa po dwukropku ma być taka sama jak nazwa pobranego pliku. Jeżeli właśnie to widać, a adres w pasku się nie zmienił, plik jest dostępny i przyczyna leży gdzie indziej, zwykle w niezgodności adresu usługi albo w zabezpieczeniach serwera, które inaczej traktują zwykłego odwiedzającego, a inaczej automat Google.

Jak odczytać wynik testu?

Strona z napisem o błędzie 404 albo zwykła podstrona serwisu z komunikatem „nie znaleziono” oznacza, że pliku nie ma w tym katalogu, z którego serwer podaje stronę. Rozwiązanie opisuje kolejna sekcja.

Okno z prośbą o login i hasło, komunikat o braku dostępu albo plansza „strona w budowie” oznaczają blokadę po stronie serwera lub wtyczki. Ten przypadek jest omówiony w części o zabezpieczeniach.

Jeśli adres w pasku zmienił się po załadowaniu, na przykład z wersji bez www na wersję z www albo z http na https, działa przekierowanie. Wtedy trzeba przejść do części o adresie usługi.

Jeżeli zamiast jednego wiersza wyświetla się pełna strona z menu i stopką albo inny tekst, pod tym adresem serwer podaje coś innego niż oryginalny plik. Tak bywa, gdy plik został otwarty i zapisany w edytorze albo gdy jego treść wklejono do systemu zarządzania treścią jako zwykłą podstronę.

Plik trafił do złego katalogu. Jak znaleźć właściwy?

To najczęstsza przyczyna komunikatu o nieznalezieniu pliku. Po połączeniu z serwerem widać zwykle kilka katalogów i nie jest oczywiste, który z nich odpowiada adresowi strony. Plik wgrany o jeden poziom za wysoko albo do katalogu innej domeny fizycznie istnieje, ale pod oczekiwanym adresem się nie otwiera.

Katalog główny strony nosi u różnych dostawców różne nazwy, najczęściej public_html, www, htdocs albo nazwę domeny. Jeśli na jednym koncie hostingowym działa kilka stron, każda ma własny katalog, a ich przypisanie widać w panelu hostingu, w części poświęconej domenom. Nie należy zgadywać: przypisanie katalogu do domeny trzeba odczytać z panelu albo uzyskać od pomocy technicznej hostingu.

Właściwy katalog można też rozpoznać po zawartości. W przypadku WordPressa znajdują się w nim plik wp-config.php oraz katalogi wp-admin, wp-content i wp-includes. W przypadku innych stron zwykle leży tam plik index.php lub index.html oraz plik robots.txt.

1. Należy zalogować się do panelu hostingu i otworzyć menedżer plików albo połączyć się z serwerem programem do przesyłania plików, korzystając z danych od dostawcy.
2. W panelu hostingu, w ustawieniach domeny, trzeba odczytać, na jaki katalog wskazuje domena wpisana w Search Console. Jeśli usługa dotyczy subdomeny, na przykład sklepu pod osobnym adresem, liczy się katalog tej subdomeny.
3. Po wejściu do tego katalogu wgrywa się plik pobrany z Search Console, bezpośrednio do niego, nie do żadnego podkatalogu.
4. Po wgraniu należy porównać nazwę pliku na serwerze z nazwą w oknie weryfikacji. Dopisek w rodzaju „(1)” w nazwie oznacza, że plik pobrano kilka razy i komputer zmienił nazwę kopii. Taki plik nie zadziała.
5. Plik wgrany wcześniej w złe miejsce można usunąć, żeby nie wprowadzał zamieszania.
6. Na koniec powtarza się test w oknie incognito, a dopiero po prawidłowym wyniku klika „Zweryfikuj”.

Co zrobić, gdy strona nie daje dostępu do plików?

Część kreatorów stron i platform sklepowych w ogóle nie pozwala umieścić własnego pliku w katalogu głównym. Pomoc Google mówi o tym wprost: metoda może nie być dostępna na danej platformie, a w razie braku uprawnień do wgrania pliku należy użyć innej metody weryfikacji.

W takiej sytuacji nie warto szukać obejść. Platformy tego typu mają zwykle własne pole na kod weryfikacyjny Google albo gotowe połączenie z Search Console, opisane w ich pomocy. Dla WordPressa Google wskazuje wtyczkę Site Kit, która przeprowadza weryfikację samodzielnie.

Kto woli nie zajmować się tym samodzielnie, może zadzwonić pod numer 533 525 168 albo napisać na info@lukaszwudyka.pl. Ustalę wtedy, dlaczego Google nie widzi pliku, umieszczę go we właściwym miejscu albo dobiorę inną metodę i doprowadzę weryfikację do końca.

Adres usługi w Search Console różni się od adresu strony. Jak to sprawdzić?

Usługa z prefiksem URL obejmuje wyłącznie adresy zaczynające się dokładnie od wpisanego prefiksu. Dla Search Console http://przyklad.pl/, https://przyklad.pl/ i https://www.przyklad.pl/ to trzy różne usługi. Plik jest szukany pod tym wariantem, który został wpisany przy dodawaniu usługi, a nie pod tym, pod którym strona faktycznie działa.

Stąd bierze się częsty scenariusz: strona działa pod adresem z https i www, a usługa została dodana bez www albo z http. Plik leży na serwerze poprawnie, ale wejście pod adres usługi kończy się przekierowaniem na inny wariant.

Jak Google traktuje przekierowania przy tej metodzie?

Pomoc Google jest tu ostrożna i sam radzę przyjąć najbezpieczniejsze założenie. W opisie kroków napisano, że Search Console nie śledzi przekierowań podczas szukania pliku. W opisie błędów doprecyzowano, że nie są obsługiwane przekierowania do innej domeny, natomiast przekierowania w obrębie tej samej domeny, na przykład na wersję z www lub na https, są obsługiwane.

W praktyce najpewniej jest doprowadzić do tego, żeby plik otwierał się bezpośrednio pod adresem usługi, bez żadnego przekierowania. Jeżeli cały ruch ze starej domeny jest kierowany na nową, plik pod starą domeną nie zostanie zaakceptowany. Google zaleca wtedy weryfikację tagiem HTML.

Jak dodać usługę pod właściwym adresem?

Najprostszą naprawą nie jest przerabianie przekierowań, tylko dodanie usługi dla tego wariantu adresu, pod którym strona rzeczywiście się otwiera. Właściwy wariant widać w pasku adresu po wejściu na stronę główną w oknie incognito.

W Search Console należy rozwinąć listę usług w lewym górnym rogu, kliknąć „Dodaj usługę”, wybrać usługę z prefiksem URL i wkleić adres skopiowany z paska przeglądarki, z początkiem https:// i końcowym ukośnikiem. Ten sam plik weryfikacyjny działa dla wszystkich usług dodawanych z tego samego konta Google, więc jeśli już leży w katalogu głównym, weryfikacja nowej usługi powinna przejść od razu.

Starszej, błędnie dodanej usługi nie trzeba usuwać, ale też nie należy się nią sugerować przy czytaniu raportów. Jeśli przekierowania na stronie same wymagają uporządkowania, przyda się osobny wpis o tym, jak ustawić przekierowanie 301 w pliku .htaccess bez ryzyka wyłączenia całej strony.

Nazwa lub zawartość pliku została zmieniona. Jak to naprawić?

Komunikat o nieprawidłowej zawartości oznacza, że Google dotarł do pliku, ale w środku znalazł coś innego, niż wydał. Powodów jest kilka i każdy wygląda niewinnie.

Pierwszy to otwarcie pliku w edytorze tekstu i ponowne zapisanie. Niektóre programy dodają przy tym niewidoczne znaki na początku pliku albo zmieniają sposób zapisu, co wystarcza, żeby treść przestała się zgadzać. Drugi to przesłanie właścicielowi strony samej treści pliku w wiadomości, a potem odtworzenie pliku ręcznie. Trzeci to wklejenie treści do nowej podstrony w systemie zarządzania treścią, przez co pod adresem pojawia się cała strona z szablonem zamiast jednego wiersza.

Czwarty powód dotyczy osób: plik został pobrany z konta informatyka albo agencji, a weryfikację próbuje przeprowadzić właściciel firmy na swoim koncie. Plik jest powiązany z konkretnym kontem Google, więc potwierdza własność tylko tej osobie, która go pobrała.

Naprawa jest w każdym przypadku taka sama. Należy zalogować się do Search Console na tym koncie, które ma zostać właścicielem, pobrać plik jeszcze raz z okna weryfikacji i wgrać go na serwer bez otwierania i bez zmiany nazwy, zastępując poprzednią wersję. Jeśli plik wgrywa ktoś inny, należy mu przekazać sam plik jako załącznik, nie jego treść.

Na serwerze mogą bez przeszkód leżeć obok siebie pliki weryfikacyjne kilku osób. Każdy ma inną nazwę i każdy potwierdza własność innego konta. Trzeba tylko uważać, żeby przy wgrywaniu własnego pliku nie usunąć cudzego, bo ta osoba straci wtedy dostęp.

Serwer, zapora albo wtyczka nie wpuszczają Google. Gdzie szukać blokady?

Jeśli plik leży we właściwym katalogu i ma poprawną treść, a Google nadal zgłasza błąd, najczęściej coś stoi między plikiem a światem zewnętrznym. Search Console opisuje to zwykle jako nieprawidłową odpowiedź serwera albo brak możliwości połączenia.

Hasło, tryb konserwacji i strona w budowie

Strony w trakcie budowy bywają chronione hasłem na poziomie serwera albo wtyczką, która wszystkim niezalogowanym pokazuje planszę zastępczą. Właściciel zalogowany do panelu widzi wtedy stronę normalnie i nie podejrzewa blokady. Test w oknie incognito ujawnia ją natychmiast.

Na czas weryfikacji i na przyszłość plik musi być wyłączony spod takiej ochrony. Najprościej wyłączyć tryb konserwacji przed kliknięciem „Zweryfikuj”. Trzeba jednak wiedzieć, że Google sprawdza plik okresowo, więc ponowne zamknięcie całej strony hasłem doprowadzi po pewnym czasie do utraty weryfikacji.

Zapora, ochrona przed botami i sieć CDN

Zapory aplikacyjne, wtyczki bezpieczeństwa i usługi pośredniczące w ruchu potrafią przepuszczać ludzi, a zatrzymywać automaty. Wtedy plik otwiera się w przeglądarce poprawnie, a mimo to weryfikacja się nie udaje.

Google pobiera plik weryfikacyjny własnym automatem, który w dokumentacji technicznej figuruje pod nazwą Google Site Verifier i przedstawia się serwerowi jako Google-Site-Verification. Jeśli strona korzysta z zapory lub ochrony przed botami, należy w jej dzienniku zdarzeń poszukać zablokowanych wejść z taką nazwą z chwili kliknięcia „Zweryfikuj” i dodać dla nich wyjątek. Kto nie ma dostępu do takich ustawień, powinien przekazać tę nazwę pomocy technicznej hostingu.

Podobne blokady utrudniają także zwykłe odczytywanie strony przez Google. Więcej o tym mechanizmie napisałem przy okazji komunikatu „Zablokowano z powodu zabronionego dostępu (403)”.

Pamięć podręczna i reguły przepisywania adresów

Jeśli tuż po wgraniu pliku strona nadal pokazuje błąd 404, winna bywa pamięć podręczna, która zapamiętała wcześniejszą odpowiedź. Wystarczy wyczyścić pamięć podręczną we wtyczce, w panelu hostingu lub w usłudze CDN i powtórzyć test.

Rzadziej przyczyną są reguły serwera, które każde zapytanie o nieznany adres kierują do systemu strony. Jeżeli plik fizycznie leży w katalogu głównym, a pod jego adresem wyświetla się strona błędu z szablonem serwisu, sprawę powinien obejrzeć administrator serwera. Samodzielna edycja reguł serwera bez kopii zapasowej jest ryzykowna, bo jeden błąd potrafi wyłączyć całą stronę.

Po czym poznać, że naprawa zadziałała, i jak jej nie stracić?

Po usunięciu przyczyny należy wrócić do okna weryfikacji i kliknąć „Zweryfikuj”. Jeśli usługa została wcześniej zapisana przyciskiem „Zweryfikuj później”, wystarczy wybrać ją z listy usług, a okno weryfikacji otworzy się samo.

Powodzenie widać od razu: pojawia się potwierdzenie, że własność została zweryfikowana, a usługa otwiera się z pełnym menu raportów. Sprawdzenie odbywa się w chwili kliknięcia, więc nie ma potrzeby czekać z ponowną próbą, o ile przyczyna została rzeczywiście usunięta.

Puste raporty tuż po weryfikacji nie są błędem. Według pomocy Google dane są zbierane od chwili dodania usługi, ale zanim się pojawią, może minąć kilka dni. Jeśli po tym czasie nadal nic nie widać, trzeba jeszcze raz sprawdzić, czy usługa dotyczy właściwego wariantu adresu.

Stan weryfikacji można w każdej chwili obejrzeć w „Ustawieniach” usługi, w wierszu „Weryfikacja własności”. Widać tam, którą metodą własność została potwierdzona, i można dodać kolejną. Dobrym następnym ruchem po udanej weryfikacji jest zgłoszenie mapy witryny, żeby Google szybciej poznał strukturę serwisu.

Jak nie stracić weryfikacji po kilku tygodniach?

Weryfikacja nie jest jednorazową formalnością. Google okresowo sprawdza, czy plik nadal jest dostępny i poprawny. Gdy nie może tego potwierdzić, wysyła powiadomienie, a jeśli problem nie zostanie rozwiązany, uprawnienia wygasają po upływie okresu prolongaty. Usunięcie pliku z serwera oznacza więc utratę statusu zweryfikowanego właściciela.

Plik znika najczęściej przy okazji innych prac: przeniesienia strony na nowy hosting, wgrania nowej wersji serwisu na miejsce starej, przywrócenia kopii zapasowej sprzed weryfikacji albo porządków, podczas których ktoś usuwa „niepotrzebne” pliki. Dlatego nazwę pliku weryfikacyjnego należy wpisać na listę rzeczy do przeniesienia przy każdej zmianie serwera.

Najskuteczniejszym zabezpieczeniem jest druga metoda weryfikacji dodana obok pliku. Google sam to zaleca: w „Ustawieniach”, w wierszu „Weryfikacja własności”, można dodać kolejne metody, tak aby awaria jednej nie odbierała dostępu. Najtrwalszy jest rekord DNS, bo nie zależy od plików strony. Sposób jego dodania opisałem we wpisie o weryfikacji witryny przez rekord DNS.

Radzę też zadbać o to, żeby właścicielem zweryfikowanym było konto Google należące do firmy, a nie wyłącznie konto wykonawcy strony. Lista osób z dostępem znajduje się w „Ustawieniach”, w części „Użytkownicy i uprawnienia”. Jeśli wszyscy zweryfikowani właściciele stracą dostęp, nikt nie zobaczy danych usługi, dopóki ktoś nie przejdzie weryfikacji od nowa.

Plik otwiera się poprawnie, a weryfikacja nadal się nie udaje. Co dalej?

Jeśli test w oknie incognito daje prawidłowy wynik, adres usługi zgadza się z adresem strony, a plik został pobrany z właściwego konta, pozostają przyczyny po stronie serwera lub domeny. Podpowiada je treść komunikatu.

Upłynięcie limitu czasu oznacza, że serwer odpowiadał zbyt wolno albo był chwilowo niedostępny. Należy upewnić się, że strona działa, i ponowić próbę po pewnym czasie. Błąd przy sprawdzaniu nazwy domeny albo informacja, że domeny nie udało się znaleźć, wskazują na ustawienia DNS lub na literówkę w adresie usługi. Zbyt wiele przekierowań oznacza pętlę, w której adresy odsyłają do siebie nawzajem.

Błąd wewnętrzny leży po stronie Google. Pomoc zaleca w takim przypadku ponowić próbę, a gdy problem nie ustępuje, sprawdzić oficjalne forum pomocy wyszukiwarki, czy nie ma tam informacji o awarii.

Gdy mimo wszystko plik nie przechodzi, rozsądniej jest zmienić metodę, niż tracić kolejne dni. Do wyboru są: tag HTML wstawiany w kod strony głównej, kod Google Analytics lub Menedżera tagów Google, jeśli strona już z nich korzysta na koncie, do którego właściciel ma dostęp, oraz rekord DNS u dostawcy domeny. Rekord DNS pozwala przy okazji założyć usługę domeny, która obejmuje wszystkie warianty adresu naraz i usuwa kłopot z www oraz https.

Jest jeszcze jedna droga, o której łatwo zapomnieć. Jeżeli stroną zajmował się wcześniej ktoś inny i ma zweryfikowaną usługę, może po prostu nadać dostęp właścicielowi firmy. Pomoc Google wymienia to jako rozwiązanie na wypadek, gdy samodzielna weryfikacja z jakiegoś powodu nie jest możliwa.

Jakich błędów unikać przy weryfikacji plikiem?

Większość kłopotów bierze się z pośpiechu i z kilku powtarzalnych przyzwyczajeń. Poniższa lista pozwala ich uniknąć przy pierwszym podejściu.

• Otwieranie pobranego pliku w edytorze „żeby zobaczyć, co jest w środku” i zapisywanie go ponownie.
• Przesyłanie plików weryfikacyjnych między osobami i używanie pliku pobranego z cudzego konta.
• Klikanie „Zweryfikuj” wielokrotnie bez wcześniejszego testu w oknie incognito.
• Usuwanie pliku po udanej weryfikacji w przekonaniu, że nie jest już potrzebny.
• Usuwanie z serwera plików weryfikacyjnych innych osób bez ustalenia, czyje są.
• Poleganie na jednej metodzie weryfikacji i na jednym koncie, do którego dostęp ma tylko wykonawca strony.

Osobną sprawą jest komunikat o tym, że strona wygląda na zaatakowaną przez hakerów. Nie należy go lekceważyć ani próbować obchodzić inną metodą weryfikacji. Najpierw trzeba sprawdzić stronę pod kątem obcych plików i treści, a dopiero po jej oczyszczeniu wracać do Search Console.

Ostrzegam również przed udostępnianiem obcym osobom danych do serwera tylko po to, żeby „wgrały jeden plik”. Bezpieczniej jest założyć na ten czas osobne konto dostępowe z ograniczonymi uprawnieniami i usunąć je po zakończeniu pracy.

Najczęstsze pytania

Czy po udanej weryfikacji plik można usunąć z serwera?

Nie. Google okresowo sprawdza obecność pliku, a jego usunięcie prowadzi do utraty statusu zweryfikowanego właściciela. Plik powinien pozostać w katalogu głównym tak długo, jak długo ta metoda ma potwierdzać własność, chyba że wcześniej została dodana i potwierdzona inna metoda.

Czy plik weryfikacyjny wpływa na pozycję strony w Google?

Nie. Plik służy wyłącznie do potwierdzenia, kto jest właścicielem strony. Pomoc Google zaznacza, że samo dodanie usługi w Search Console nie wpływa na wyniki strony w wyszukiwarce, a błędy popełnione przy konfiguracji jej nie szkodzą.

Czy ten sam plik zadziała dla wersji z www i bez www?

Plik jest przypisany do konta Google, a nie do jednego adresu, więc ta sama osoba może nim potwierdzić kilka usług. Każdy wariant adresu trzeba jednak dodać jako osobną usługę z prefiksem URL, a plik musi się otwierać pod adresem każdej z nich. Wygodniejszym rozwiązaniem jest usługa domeny weryfikowana rekordem DNS, która obejmuje wszystkie warianty.

Czy plik robots.txt może zablokować weryfikację?

Z dokumentacji technicznej Google wynika, że automaty uruchamiane na żądanie użytkownika, do których należy mechanizm weryfikacji, zwykle nie stosują się do reguł pliku robots.txt. Przyczyną nieudanej weryfikacji jest więc najczęściej coś innego: hasło, zapora albo błędny katalog. Mimo to nie ma powodu, żeby celowo zamykać dostęp do tego pliku.

Ile osób może zweryfikować tę samą stronę plikiem?

Każda osoba pobiera własny plik o innej nazwie i wgrywa go do tego samego katalogu. Pliki nie kolidują ze sobą. Według pomocy Google liczba zweryfikowanych właścicieli nie jest ograniczona, trzeba tylko pilnować, żeby nie usuwać cudzych plików bez uzgodnienia.

Jak odebrać dostęp osobie, która zweryfikowała stronę swoim plikiem?

Samo usunięcie jej z listy użytkowników nie wystarczy, dopóki jej plik leży na serwerze, ponieważ może ona zweryfikować się ponownie. Należy usunąć z katalogu głównego plik tej osoby, a następnie w „Ustawieniach”, w części „Użytkownicy i uprawnienia”, sprawdzić listę „Nieużywane tokeny własności”, która pokazuje pozostałe ślady weryfikacji. Wcześniej trzeba upewnić się, że własność potwierdza już inne konto.

Dlaczego po zmianie hostingu weryfikacja przestała działać?

Najczęściej plik weryfikacyjny nie został przeniesiony na nowy serwer razem z resztą strony, bo nie należy do systemu zarządzania treścią i łatwo go pominąć. Wystarczy pobrać plik ponownie z Search Console, wgrać go do katalogu głównego na nowym serwerze i kliknąć „Zweryfikuj”. Dane zebrane wcześniej pozostają w usłudze.

Czy usługę domeny da się zweryfikować plikiem HTML?

Nie. Plik HTML działa tylko dla usługi z prefiksem URL. Usługa domeny, obejmująca wszystkie subdomeny i oba protokoły, wymaga potwierdzenia u dostawcy nazwy domeny, czyli dodania rekordu DNS.

Brak czasu albo ochoty, żeby zająć się tym samodzielnie?

Weryfikacja strony w Search Console to drobna czynność, która potrafi zabrać cały wieczór, gdy coś nie chce zadziałać. Chętnie zrobię to od początku do końca: sprawdzę, dlaczego Google nie widzi pliku, umieszczę go we właściwym katalogu albo dodam trwalszą metodę, uporządkuję warianty adresu strony, zadbam o to, żeby właścicielem usługi było konto firmy, i pokażę, gdzie potem zaglądać po najważniejsze informacje.

Wystarczy zadzwonić pod numer 533 525 168 albo napisać na adres info@lukaszwudyka.pl i podać adres strony. Odpowiem, czego będę potrzebować, i przejmę resztę.