Technologia

SEO techniczne przed startem strony: lista kontrolna od stagingu do Search Console

Indeksowanie, robots.txt, mapa strony, canonical, renderowanie, wydajność i dane strukturalne. Co sprawdzić na wersji testowej, co w dniu uruchomienia, a co w pierwszych tygodniach.

DualFroz - VulCode CEO·29 sierpnia 2026·20 min czytania

Nowa strona, która przez pierwszy miesiąc nie pojawia się w Google, często nie ma problemu z treścią, tylko z ustawieniem przeniesionym z wersji testowej: noindex w nagłówku, Disallow: / w pliku robots.txt albo canonical wskazujący adres stagingu. Dlatego SEO techniczne przed startem strony zaczyna się od wersji testowej, a nie od słów kluczowych. Każdy z tych błędów da się wykryć jednym poleceniem przed uruchomieniem, a po starcie potrafi kosztować tygodnie.

Cała lista sprowadza się do czterech pytań: czy robot może pobrać każdą ważną podstronę, czy dostaje w HTML-u jej treść, czy wie, który adres jest właściwy, i czy nie trafi na wersję, która nie powinna być publiczna. Punkty są ułożone w kolejności: najpierw staging, potem dzień startu, na końcu pierwsze tygodnie w Search Console. Przy każdym jest sposób sprawdzenia, który nie wymaga płatnych narzędzi.

W skrócie

Wersję testową zamykasz hasłem na serwerze, a nie plikiem robots.txt. Robots.txt blokuje pobieranie, a nie indeksowanie.
Każda podstrona ma jeden adres. Pozostałe warianty (http, bez www, z ukośnikiem na końcu) przekierowują na niego jednym przekierowaniem 301.
Mapa strony zawiera tylko adresy kanoniczne, które zwracają kod 200. Google ignoruje w niej priority i changefreq.
Treść i linki muszą być w HTML-u, który dostaje robot, a nie dopiero po wykonaniu JavaScriptu.
W dniu startu: Search Console z weryfikacją przez DNS, zgłoszona mapa strony, sprawdzone najważniejsze adresy. Indeksowanie trwa od kilku dni do kilku tygodni.

Wersja testowa, która nie trafi do Google

Strona przez kilka tygodni żyje pod adresem testowym, na przykład staging.example.com. Wystarczy, że ktoś wklei ten adres w publicznym zgłoszeniu błędu albo na forum, a Google może go znaleźć i zaindeksować. Wtedy w wynikach pojawiają się dwie wersje tej samej strony, a testowa bywa pełna treści zastępczych.

Najczęstsza reakcja to dopisanie Disallow: / w pliku robots.txt stagingu, a to nie działa tak, jak się wydaje. Google pisze w dokumentacji robots.txt, że ten plik nie jest mechanizmem do trzymania strony poza wynikami wyszukiwania. Adres zablokowany w robots.txt może pojawić się w wynikach bez opisu, jeśli prowadzą do niego linki. Do tego robot, który nie może pobrać strony, nie zobaczy umieszczonego na niej znacznika noindex, więc dopisanie blokady w robots.txt wyłącza właśnie tę blokadę, która działa.

Skuteczna ochrona to hasło na poziomie serwera. Robot dostaje odpowiedź 401, nie widzi treści i nie ma czego indeksować. Nagłówek X-Robots-Tag: noindex warto dodać jako drugą warstwę, na wypadek gdyby ktoś na chwilę wyłączył hasło, żeby pokazać stronę klientowi.

staging.conf

server {
    listen 443 ssl;
    server_name staging.example.com;
    ssl_certificate     /etc/letsencrypt/live/staging.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/staging.example.com/privkey.pem;

    auth_basic "Staging";
    auth_basic_user_file /etc/nginx/.htpasswd-staging;
    add_header X-Robots-Tag "noindex, nofollow" always;

    root /var/www/staging;
}

Słowo always sprawia, że nginx wysyła nagłówek także przy odpowiedzi 401. Ważne jest też to, gdzie blokada mieszka: w konfiguracji serwera stagingu, a nie w kodzie strony. Kod przechodzi na produkcję, konfiguracja testowego serwera zostaje na miejscu, więc blokada nie przejdzie razem z wdrożeniem.

Inaczej jest z ustawieniami zapisanymi w bazie danych. W WordPressie opcja w ustawieniach czytania, która prosi wyszukiwarki o nieindeksowanie witryny, od wersji 5.3 dodaje do każdej strony znacznik <meta name='robots' content='noindex, nofollow' />, co opisuje notatka zespołu WordPressa. Jeśli zaznaczysz ją na stagingu, a potem przeniesiesz bazę na produkcję, przeniesiesz też noindex. Dlatego pierwszy test w dniu startu robi się na docelowej domenie:

sprawdz-blokady.sh · bash

curl -sI https://www.example.com/ | grep -i '^x-robots-tag'
curl -s https://www.example.com/ | grep -io '<meta[^>]*robots[^>]*>'
curl -s https://www.example.com/robots.txt

Pierwsze polecenie na produkcji nie powinno zwrócić nic. Drugie nic albo znacznik z index, follow. Trzecie ma pokazać plik bez linii Disallow: /. Wzorzec w drugim poleceniu nie zakłada rodzaju cudzysłowu, bo WordPress używa apostrofów, a inne systemy cudzysłowów.

Jeden adres dla każdej podstrony: HTTPS, www i ukośnik na końcu

Ta sama strona główna może odpowiadać pod czterema adresami: z http i https, z www i bez. Do tego dochodzi wariant z ukośnikiem na końcu ścieżki i bez niego, a w niektórych systemach także z index.html. Dla Google to osobne adresy. Wyszukiwarka wybierze z nich jeden jako kanoniczny, ale linki z zewnątrz rozkładają się na warianty, a w raportach ruch jednej strony bywa rozbity na kilka pozycji.

Którą wersję wybierzesz jako główną, to Twoja decyzja. Ważne, żeby była jedna i żeby każdy pozostały wariant przekierowywał na nią jednym przekierowaniem 301, a nie łańcuchem z http://example.com przez https://example.com do https://www.example.com.

domena.conf

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://www.example.com$request_uri;
}

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    return 301 https://www.example.com$request_uri;
}

Certyfikat musi obejmować obie nazwy, z www i bez, bo przeglądarka i robot najpierw zestawiają połączenie szyfrowane, a dopiero potem dostają przekierowanie. Wynik sprawdzisz pętlą, która odpytuje wszystkie cztery warianty:

warianty.sh · bash

for url in http://example.com http://www.example.com https://example.com https://www.example.com; do
  curl -s -o /dev/null -w "$url -> %{http_code} %{redirect_url}\n" "$url/"
done

Poprawny wynik wygląda tak: trzy warianty zwracają 301 z tym samym adresem docelowym, a czwarty zwraca 200 bez przekierowania.

wynik.txt

http://example.com -> 301 https://www.example.com/
http://www.example.com -> 301 https://www.example.com/
https://example.com -> 301 https://www.example.com/
https://www.example.com -> 200

Google przy wyborze adresu kanonicznego preferuje HTTPS, jeśli nic temu nie przeczy. Tak samo ustal jedną konwencję dla ukośnika na końcu ścieżki i trzymaj się jej w linkach wewnętrznych, mapie strony i canonicalach.

Kody odpowiedzi: 200, 301 i prawdziwe 404

Wpisz adres, który na pewno nie istnieje. Odpowiedź musi mieć kod 404 albo 410, a nie 200 z komunikatem "nie znaleziono" i nie przekierowanie na stronę główną. Sytuację, w której serwer mówi, że wszystko w porządku, a treść mówi, że strony nie ma, Google nazywa pozornym błędem 404 (soft 404).

404.sh · bash

curl -s -o /dev/null -w '%{http_code}\n' https://www.example.com/tej-strony-nie-ma-123

Oczekiwany wynik to 404. W aplikacjach renderowanych w przeglądarce to częsty błąd, bo serwer na każdy adres zwraca ten sam plik HTML z kodem 200, a komunikat o braku strony rysuje dopiero JavaScript. Dokumentacja Google o JavaScripcie podaje dwa wyjścia: przekierować w JavaScripcie na adres, dla którego serwer zwraca 404, albo dodać do takiej strony noindex. Najprościej jednak, gdy serwer zna listę istniejących tras i od razu odpowiada właściwym kodem.

Druga rzecz to przerwy techniczne. Jeśli podczas wdrożenia strona na kilka minut pokazuje komunikat o pracach, powinna zwracać kod 503, a nie 200. Google przy błędach 5xx tymczasowo zwalnia pobieranie strony i ignoruje treść takiej odpowiedzi. Strona z kodem 200 i tekstem "trwają prace" to dla robota nowa treść strony głównej.

robots.txt: plik, który ma niczego nie blokować przypadkiem

Na nowej stronie firmowej robots.txt zwykle jest krótki. Jego rolą nie jest ukrywanie stron, tylko oszczędzanie pracy robota na adresach bez wartości w wynikach: koszyku, wynikach wyszukiwarki wewnętrznej, filtrach, które generują tysiące kombinacji parametrów.

robots.txt

User-agent: *
Disallow: /koszyk/
Disallow: /szukaj

Sitemap: https://www.example.com/sitemap.xml

Kilka zasad z opisu robots.txt w dokumentacji Google, które mają znaczenie przy starcie:

Zasięg. Plik działa tylko dla hosta, protokołu i portu, pod którym leży. https://www.example.com/robots.txt nie dotyczy https://sklep.example.com.
Rozmiar. Google czyta pierwsze 500 KiB pliku, a resztę ignoruje.
Pamięć podręczna. Google zwykle trzyma treść pliku do 24 godzin, więc poprawka nie zadziała w minutę po wgraniu.
Kody odpowiedzi. Gdy robots.txt zwraca 404, Google uznaje, że ograniczeń nie ma. Gdy zwraca błąd 5xx, przez pierwsze 12 godzin wstrzymuje pobieranie strony, a potem przez 30 dni korzysta z ostatniej znanej wersji. Plik, który przez błąd konfiguracji zwraca 500, potrafi więc zatrzymać pobieranie całej witryny.
Konflikty reguł. Wygrywa reguła o najdłuższej ścieżce, a przy remisie ta mniej restrykcyjna.
Zasoby strony. Nie blokuj plików CSS i JavaScript, bez których robot nie zrozumie wyglądu i treści strony.

Najgroźniejszy błąd w dniu startu to robots.txt skopiowany ze stagingu razem z Disallow: /. Dlatego plik powinien być generowany osobno dla każdego środowiska albo, jeszcze prościej, staging nie powinien go potrzebować, bo jest zamknięty hasłem.

Osobną decyzją jest blokowanie robotów, które zbierają dane do trenowania modeli. Według dokumentacji robotów Google token Google-Extended nie wpływa na obecność strony w wyszukiwarce ani nie jest sygnałem rankingowym, więc jego zablokowanie nie zaszkodzi widoczności. Zablokowanie z rozpędu zwykłego Googlebota zaszkodzi.

Mapa strony XML: tylko adresy, które mają być w wynikach

Mapa strony to lista adresów, które chcesz widzieć w wynikach wyszukiwania, a nie wszystkich plików na serwerze. Każdy wpis powinien spełniać trzy warunki: jest pełnym adresem z protokołem i domeną, zwraca kod 200 i jest adresem kanonicznym, czyli nie przekierowuje i nie ma noindex.

sitemap.xml · xml

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://www.example.com/uslugi/strony-internetowe</loc>
    <lastmod>2026-08-27</lastmod>
  </url>
</urlset>

Według instrukcji Google dotyczącej map witryn jeden plik może mieć najwyżej 50 000 adresów albo 50 MB przed kompresją, a większe witryny dzielą mapę na kilka plików połączonych indeksem. Plik musi być zapisany w UTF-8. Wartości priority i changefreq Google ignoruje, więc nie ma sensu nad nimi pracować. lastmod jest używany, ale tylko wtedy, gdy jest konsekwentnie i sprawdzalnie zgodny z prawdą. Generator, który przy każdym budowaniu wpisuje wszystkim stronom dzisiejszą datę, uczy Google, że ta wartość nic nie znaczy.

Mapa powinna powstawać automatycznie z tych samych danych, z których powstają trasy strony. Ręcznie prowadzony plik rozjeżdża się z rzeczywistością przy pierwszej nowej podstronie. Przed startem sprawdź, czy każdy adres z mapy zwraca 200:

sprawdz-sitemap.sh · bash

curl -s https://www.example.com/sitemap.xml \
  | grep -o '<loc>[^<]*</loc>' \
  | sed 's/<[^>]*>//g' \
  | while read -r url; do
      printf '%s %s\n' "$(curl -s -o /dev/null -w '%{http_code}' "$url")" "$url"
    done \
  | grep -v '^200 '

Pusty wynik oznacza, że wszystkie adresy odpowiadają kodem 200. Każda wypisana linia to przekierowanie, błąd albo strona, która nie istnieje. Przejrzyj też, czy w mapie nie ma domeny stagingu. Zdarza się to, gdy adres bazowy strony pochodzi ze zmiennej środowiskowej ustawionej na serwerze testowym.

Canonical: wskazówka, którą łatwo zepsuć jedną zmienną

Znacznik <link rel="canonical"> mówi, który adres jest główną wersją strony. Każda podstrona, która ma być w wynikach, powinna wskazywać samą siebie pełnym adresem bez parametrów. Wtedy wersja z ?utm_source=newsletter wskazuje adres czysty i nie konkuruje z nim w indeksie.

Google traktuje canonical jako silny sygnał, ale nie jako polecenie. W opisie konsolidacji adresów wymienia trzy metody: przekierowania i canonical jako sygnały silne oraz obecność w mapie strony jako sygnał słaby. Działa to dobrze, gdy wszystkie sygnały mówią to samo. Gdy canonical wskazuje jeden adres, mapa strony drugi, a linki wewnętrzne trzeci, Google wybiera sam i nie musi wybrać tego, co chciałeś.

Typowe błędy przy starcie wyglądają tak:

Domena stagingu w canonicalu. Adres bazowy pochodzi ze zmiennej środowiskowej, której nikt nie zmienił. Każda strona produkcyjna mówi wtedy, że jej główna wersja leży na serwerze testowym za hasłem.
Jeden canonical na całej stronie. Szablon wpisuje adres strony głównej na wszystkich podstronach, co dla Google oznacza, że reszta to duplikaty strony głównej.
Canonical zmieniany przez JavaScript. Google odradza ustawianie w JavaScripcie innego adresu niż ten, który jest w pierwotnym HTML-u.
Adres względny. href="/kontakt" zamiast pełnego adresu. Google zaleca adresy bezwzględne.
Noindex zamiast canonicala. Google wprost odradza używanie noindex do wskazywania, który z duplikatów ma zostać, tak samo jak używanie do tego robots.txt.

Sprawdzenie to jedno polecenie na każdy typ szablonu: strona główna, podstrona usługi, wpis na blogu, kontakt.

canonical.sh · bash

curl -s https://www.example.com/uslugi/strony-internetowe | grep -io '<link[^>]*canonical[^>]*>'

Tytuły, opisy i nagłówki na każdej podstronie

Ta część jest na granicy SEO technicznego i treści, ale błędy w niej są techniczne: szablon, który nadaje wszystkim podstronom ten sam tytuł, albo pole tytułu w CMS-ie, którego nikt nie wypełnił. Google w opisie linków tytułowych zaleca, żeby każda strona miała własny element <title>, bez powtarzanego na wszystkich podstronach szablonowego tekstu i bez wyliczania słów kluczowych. Jeśli tytuł nie pasuje do treści, Google może wyświetlić w wynikach coś innego, na przykład nagłówek H1.

Opis meta nie jest wyświetlany zawsze, ale jest kandydatem na fragment pod tytułem w wynikach. Napisz go dla każdej ważnej podstrony tak, żeby odpowiadał na pytanie, z którym ktoś trafia na tę stronę. Strony bez opisu dostaną fragment wycięty automatycznie z treści.

Przy okazji sprawdź, czy każda podstrona ma jeden nagłówek H1, który mówi, o czym jest, i czy tytuł jest w tym samym języku co treść strony.

Renderowanie: czy treść jest w HTML-u, zanim zadziała JavaScript

Google uruchamia JavaScript w aktualnej wersji Chromium, ale robi to w osobnym kroku. Strona najpierw jest pobierana, potem czeka w kolejce do renderowania, a dopiero po wyrenderowaniu jej treść trafia do indeksu. Według dokumentacji Google czekanie w kolejce może trwać kilka sekund, ale może też trwać dłużej. Ta sama dokumentacja nazywa renderowanie po stronie serwera albo prerendering dobrym pomysłem, bo strona jest szybsza i dla ludzi, i dla robotów. Renderowanie dynamiczne, czyli osobna wersja dla robotów, jest według Google obejściem, a nie rozwiązaniem długoterminowym.

Najprostszy test nie wymaga żadnego narzędzia SEO. Pobierz stronę bez przeglądarki i poszukaj w niej zdania, które widzisz na ekranie:

render.sh · bash

curl -s https://www.example.com/uslugi/strony-internetowe | grep -c 'Projektujemy strony'

Wynik 0 oznacza, że zdania nie ma w HTML-u wysyłanym przez serwer i pojawia się dopiero po wykonaniu JavaScriptu. Google może je mimo to zobaczyć, ale strona zależy wtedy od kolejki renderowania i od tego, czy cały kod wykona się u robota bez błędu. Strona, którą czytasz, jest generowana do statycznego HTML-u w czasie budowania.

Przy aplikacjach napisanych w React, Vue czy Angularze sprawdź jeszcze cztery rzeczy:

Linki to znaczniki <a href>. Element, który przenosi na inną podstronę tylko przez obsługę kliknięcia, dla robota nie jest linkiem i nie prowadzi do odkrycia kolejnych adresów.
Adresy bez krzyżyka. Routing oparty na fragmentach (/#/uslugi) utrudnia robotowi odczytanie adresów. Google zaleca History API.
Noindex w pierwotnym HTML-u. Jeśli serwer wysyła noindex, a JavaScript go usuwa, Google może w ogóle nie uruchomić renderowania i zostać przy noindex.
Treść po interakcji. Google indeksuje wersję mobilną strony i nie wczytuje treści, która wymaga kliknięcia, przewinięcia karuzeli czy wpisania tekstu. Akordeon jest w porządku, jeśli jego zawartość jest w HTML-u od początku.

Jak wygląda strona z punktu widzenia Google, pokazuje narzędzie do sprawdzania adresów URL w Search Console. Opcja "Sprawdź URL wersji opublikowanej" pobiera stronę na żywo i pokazuje wyrenderowany HTML oraz zrzut ekranu, więc od razu widać, czy po stronie robota coś się nie załadowało.

Wydajność i wersja mobilna przed startem

Od lipca 2024 roku Google pobiera i indeksuje wszystkie strony robotem dla smartfonów. Dokumentacja o indeksowaniu mobilnym mówi wprost, że do indeksowania i oceny pozycji używana jest wersja mobilna treści. Wersja na telefon musi więc mieć tę samą treść, tytuły, opisy i dane strukturalne co wersja na komputer. Tekst usunięty z kodu wersji mobilnej "dla czytelności" dla Google nie istnieje.

Wydajność mierzy się w Core Web Vitals, a Google publikuje progi dobrego wyniku:

Metryka	Co mierzy	Dobry wynik
LCP	Czas wyrenderowania największego elementu w widoku	do 2,5 s
INP	Czas od interakcji do następnej klatki na ekranie	poniżej 200 ms
CLS	Przesunięcia układu bez udziału użytkownika	poniżej 0,1

Nowa strona nie ma jeszcze danych od prawdziwych użytkowników, więc przed startem zostaje pomiar laboratoryjny w PageSpeed Insights. Mierz zbudowaną wersję produkcyjną i każdy typ szablonu osobno, bo najcięższa bywa podstrona, której nikt nie ogląda przy odbiorze. Wynik często psują: obraz w pierwszym ekranie oznaczony loading="lazy", obrazy bez atrybutów width i height oraz font, który po wczytaniu zmienia szerokość tekstu.

Proporcje warto znać. Google pisze w opisie doświadczenia na stronie, że zawsze stara się pokazać najbardziej trafne treści, nawet jeśli wrażenia ze strony są słabsze, i że nie istnieje jeden sygnał "page experience". Szybka strona nie wyprzedzi trafniejszej, ale przy wielu podobnie dobrych wynikach szybkość pomaga. Strony, które oddajemy, mają wynik 95+ w PageSpeed. To standard jakości strony, a nie obietnica pozycji.

Dane strukturalne: co ma sens na stronie firmowej w 2026 roku

Dane strukturalne opisują stronę w formacie, który maszyna czyta bez zgadywania: firma, jej logo i NIP, artykuł z datą publikacji. Google zaleca format JSON-LD i stawia jeden warunek, którego nie wolno obchodzić: dane muszą opisywać treść widoczną na stronie, na której są umieszczone.

Na typowej stronie firmowej sens mają cztery typy:

Organization na stronie głównej albo stronie "o nas". Google nie wymaga w nim żadnych pól, a wśród zalecanych wymienia między innymi logo, address, vatID, taxID i sameAs.
LocalBusiness zamiast Organization, jeśli firma obsługuje klientów na miejscu. Zawiera adres, telefon i godziny otwarcia.
BreadcrumbList na podstronach, żeby opisać ich miejsce w strukturze strony.
Article we wpisach na blogu, z datą publikacji i autorem.

organization.html · html

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Przykładowa Firma",
  "legalName": "Przykładowa Firma sp. z o.o.",
  "url": "https://www.example.com/",
  "logo": "https://www.example.com/logo.png",
  "vatID": "PL0000000000",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "ul. Przykładowa 1",
    "postalCode": "00-001",
    "addressLocality": "Warszawa",
    "addressCountry": "PL"
  },
  "sameAs": ["https://www.linkedin.com/company/przykladowa-firma"]
}
</script>

Poprawne dane strukturalne są warunkiem wyników rozszerzonych, a nie ich gwarancją. Jedna zmiana z tego roku ma znaczenie przy planowaniu: od 7 maja 2026 Google nie pokazuje już wyników rozszerzonych FAQ, także dla stron rządowych i medycznych, które jako ostatnie mogły je dostać. Dodawanie znacznika FAQPage w nadziei na rozwinięte pytania pod wynikiem nie ma już uzasadnienia.

Poprawność sprawdzisz w Teście wyników z elementami rozszerzonymi (Rich Results Test), który mówi, czy dany typ kwalifikuje się do wyświetlania w Google, i w Schema Markup Validator, który sprawdza samą zgodność ze słownikiem schema.org.

Czego nie trzeba robić przed startem

Każdy punkt poniżej wynika z dokumentacji Google, a nie z opinii:

Czynność	Dlaczego można ją pominąć
Znacznik meta keywords	Google pisze wprost, że go nie używa i nie ma on wpływu na indeksowanie ani pozycje
Ustawianie `priority` i `changefreq` w mapie strony	Google ignoruje obie wartości
Wysyłanie mapy strony przez adres "ping"	Google wycofał ten mechanizm, zapowiedź z czerwca 2023 roku mówiła o wyłączeniu po pół roku. Zostają Search Console i linia `Sitemap` w robots.txt
Plik llms.txt dla wyszukiwarki	Według dokumentacji Google z czerwca 2026 nie jest potrzebny w wyszukiwarce i nie wpływa na widoczność ani pozycje
Znacznik FAQPage dla rozwiniętych pytań	Wyniki rozszerzone FAQ nie są wyświetlane od 7 maja 2026
Prośba o zindeksowanie każdego adresu z osobna	Narzędzie ma dzienny limit, a ponawianie prośby o ten sam adres nie przyspiesza indeksowania

Źródła: nieobsługiwane znaczniki meta, wycofanie adresu ping, zmiany w dokumentacji Google i prośba o ponowne zindeksowanie.

Search Console w dniu startu

Search Console najlepiej założyć jeszcze przed startem, jako usługę domeny weryfikowaną rekordem DNS. Obejmuje ona wszystkie subdomeny i protokoły naraz, więc zobaczysz w niej także to, czy do indeksu nie trafiło coś ze stagingu. Weryfikacja przez DNS nie zależy od kodu strony, więc nie zniknie przy kolejnym wdrożeniu.

W samym dniu uruchomienia kolejność wygląda tak:

Blokady zdjęte na docelowej domenie

nagłówek X-Robots-Tag, znacznik meta robots i robots.txt sprawdzone poleceniami z pierwszej sekcji.

Warianty adresu

cztery warianty domeny, każdy jednym przekierowaniem 301 na wersję główną.

Żadnych śladów stagingu

wyszukanie domeny testowej w zbudowanych plikach, na przykład grep -rl "staging.example.com" dist/, zwraca pusty wynik.

Prawdziwe 404

losowy adres zwraca 404, a nie 200 ani przekierowanie.

Mapa strony

wszystkie adresy zwracają 200, mapa zgłoszona w raporcie Mapy witryn.

Najważniejsze adresy

strona główna i najważniejsze podstrony sprawdzone narzędziem do sprawdzania adresów URL, z prośbą o zindeksowanie dla kilku z nich.

Pomiar wydajności

PageSpeed Insights na produkcji dla każdego typu szablonu, wyniki zapisane jako punkt odniesienia.

Potem trzeba poczekać. Google podaje, że pobranie strony może trwać od kilku dni do kilku tygodni, a prośba o zindeksowanie nie gwarantuje, że strona trafi do wyników od razu ani w ogóle.

Pierwsze tygodnie po starcie: jak czytać raport Indeksowanie stron

Raport Indeksowanie stron w Search Console dzieli adresy na zindeksowane i niezindeksowane, a przy tych drugich podaje powód. W pierwszych tygodniach większość powodów jest normalna. Problem zaczyna się wtedy, gdy powód nie zgadza się z tym, co zamierzałeś.

Status w raporcie	Co znaczy	Co zrobić
Strona wykryta - obecnie niezindeksowana	Google zna adres, ale jeszcze go nie pobrał	Na nowej stronie nic, to kolejka. Jeśli trwa miesiącami, sprawdź linki wewnętrzne do tych stron
Strona zeskanowana, ale jeszcze niezindeksowana	Pobrana, ale na razie poza indeksem	Sprawdź, czy treść nie jest cienka albo bardzo podobna do innej podstrony
Duplikat, wyszukiwarka Google wybrała inną stronę kanoniczną niż użytkownik	Twój canonical został zignorowany	Ujednolij sygnały: canonical, mapa strony, linki wewnętrzne, przekierowania
Alternatywna strona zawierająca prawidłowy tag strony kanonicznej	Wariant, na przykład z parametrem, wskazuje wersję główną	Nic, tak ma być
URL zawiera tag "noindex"	Strona wyklucza się sama	Sprawdź, czy to zamierzone. Na stronie usług to prawie zawsze błąd
URL zablokowany przez plik robots.txt	Robot nie może pobrać adresu	Sprawdź, czy reguła nie obejmuje więcej, niż miała
Pozorny błąd 404	Strona z kodem 200 wygląda na pustą albo na komunikat o błędzie	Zwracaj 404 dla nieistniejących adresów albo uzupełnij treść
Strona zawierająca przekierowanie	Adres przekierowuje gdzie indziej	Nic, jeśli to warianty domeny. Usuń takie adresy z mapy strony

Nazwy statusów pochodzą z pomocy Search Console. Obok raportu indeksowania obserwuj raport skuteczności: zakładka Zapytania pokazuje, z czym Google kojarzy stronę, zanim zacznie ją wysoko pokazywać. Jeśli masz dostęp do logów serwera, sprawdzaj w nich odpowiedzi 404 i 5xx dla Googlebota.

W tym samym czasie strona dostaje pierwszy prawdziwy ruch i pierwsze zmiany od zespołu klienta: wtyczki, skrypty marketingowe, nowe podstrony. Co jeszcze obserwować w tym okresie, opisaliśmy we wpisie o monitoringu i utrzymaniu po wdrożeniu.

Najczęstsze pytania o SEO techniczne przy starcie strony

Ile trwa, zanim nowa strona pojawi się w Google?

Nie ma stałego terminu. Google podaje, że pobranie strony może trwać od kilku dni do kilku tygodni, a samo pobranie nie oznacza jeszcze zindeksowania. Zgłoszona mapa strony i linki z innych stron pomagają robotowi znaleźć adresy, ale nie da się kupić ani wymusić szybszego indeksowania.

Czy trzeba zgłaszać nową stronę do Google?

Nie trzeba, bo Google znajduje strony przez linki. Warto jednak, bo Search Console z mapą strony pokazuje, które adresy Google zna, których nie zaindeksował i dlaczego. Bez tego o błędzie z noindex dowiesz się dopiero z braku ruchu.

Czy robots.txt wystarczy, żeby ukryć wersję testową?

Nie. Robots.txt blokuje pobieranie, a nie indeksowanie, więc adres testowy może trafić do wyników bez opisu. Wersję testową zamyka się hasłem na serwerze.

Czy wynik 100 w PageSpeed poprawi pozycje?

Nie bezpośrednio. Google pokazuje przede wszystkim treści trafne, a wrażenia ze strony pomagają wtedy, gdy podobnie dobrych wyników jest wiele. Wynik punktowy z PageSpeed to test laboratoryjny, a Core Web Vitals opisują doświadczenia prawdziwych użytkowników. Pogoń za ostatnimi punktami ma sens wtedy, gdy któraś metryka jest poza progiem, a nie dla samej liczby.

Czy SEO techniczne robi się raz, przed startem?

Przed startem robi się największą część pracy. Każde późniejsze wdrożenie może jednak zmienić szablon, adres bazowy albo konfigurację serwera, a każda wtyczka w CMS-ie może dodać własne znaczniki. Polecenia z tego tekstu warto puszczać po każdej większej zmianie, a raport Indeksowanie stron przeglądać regularnie.

Jak wpisać to do zakresu projektu

"Optymalizacja SEO" w wycenie to hasło, które może oznaczać wszystko albo nic. We wpisie o tym, jak czytać wycenę software house'u, pokazywaliśmy, jak zamienić takie hasła na opis sprawdzalny przy odbiorze. Ta lista kontrolna daje gotowe punkty do takiego opisu. Jeśli dopiero przygotowujesz zapytanie, dopisz te punkty do briefu projektu, żeby każdy wykonawca wycenił to samo.

Strony, które oddajemy, mają wynik 95+ w PageSpeed, a razem z nimi dostajesz prawa do kodu i dokumentację. Jak wygląda cała droga od briefu do startu, opisujemy na stronie Jak pracujemy, a zakres usług znajdziesz w ofercie. Jeśli Twoja strona już działa i nie pojawia się w Google tak, jak powinna, napisz do nas z adresem.

Czy ten wpis był przydatny?

Zobacz też

19 min czytania

Integracje przez API: jak połączyć stronę, sklep lub panel z ERP, CRM, księgowością i płatnościami

20 min czytania

Integracja z KSeF: harmonogram obowiązku i podłączenie własnego systemu do API 2.0