Nową stronę warto przygotować pod SEO jeszcze przed zaprojektowaniem menu i makiet. Przed publikacją trzeba ustalić strukturę, docelowe adresy URL, treści, zasady indeksowania, analitykę i - jeśli nowa witryna zastępuje starą - mapę przekierowań 301.
Najdroższe błędy SEO nie powstają zwykle w dniu uruchomienia. Powstają wcześniej, gdy projektant tworzy nawigację bez analizy popytu, copywriter dostaje listę przypadkowych zakładek, a programista buduje system, który nie pozwala zarządzać metadanymi, canonicalami lub przekierowaniami.
Po publikacji można naprawić wiele rzeczy. Czasem wymaga to jednak przebudowy szablonów, ponownego pisania treści, zmiany adresów i kolejnej migracji. Lepiej podjąć najważniejsze decyzje, zanim strona zacznie zbierać ruch, linki i historię w Google.
Strona gotowa wizualnie nie zawsze jest gotowa do publikacji. Gotowa strona ma działać dla użytkownika, przekazywać dane do analityki i udostępniać wyszukiwarce właściwe treści pod właściwymi adresami.
SEO nowej strony zaczyna się przed projektem
SEO nie jest warstwą, którą dodaje się na końcu za pomocą wtyczki. Wpływa na zakres podstron, menu, szablony, nazwy kategorii, treści, sposób ładowania elementów i możliwości systemu CMS.
Przed rozpoczęciem projektowania należy odpowiedzieć na pytania:
- jakie usługi lub produkty mają generować sprzedaż,
- kim są najważniejsi użytkownicy i czego szukają,
- na jakich rynkach oraz w jakich językach działa firma,
- jakie podstrony muszą istnieć w dniu premiery,
- które treści ze starej strony trzeba zachować, połączyć albo usunąć,
- jak będzie mierzony telefon, formularz, rezerwacja lub zakup,
- kto odpowiada za SEO, treść, development, analitykę i odbiór.
Wynikiem powinien być brief SEO połączony z wymaganiami biznesowymi. Dzięki niemu zespół nie projektuje pustych ekranów, lecz strony mające określony cel, intencję i miejsce w strukturze.
Nowa domena czy nowa wersja istniejącej strony?
To dwa różne projekty. Nowa domena nie ma historii widoczności, więc głównym zadaniem jest stworzenie fundamentu do indeksowania i wzrostu. Relaunch istniejącej strony wymaga dodatkowo ochrony ruchu, pozycji oraz linków, które już zdobyto.
| Scenariusz | Najważniejsze zadanie | Główne ryzyko |
|---|---|---|
| Nowa firma i nowa domena | Architektura, treści, indeksowanie i budowa autorytetu | Publikacja zbyt małej lub niejasnej strony |
| Redesign na tej samej domenie | Zachowanie wartościowych URL-i i treści | Spadek przez usunięcie elementów wspierających pozycje |
| Zmiana domeny | Mapowanie i przekierowanie każdego wartościowego adresu | Utrata sygnałów starej domeny |
| Zmiana CMS lub platformy | Kontrola renderowania, URL-i, canonicali i funkcji SEO | Problemy generowane przez nowy system |
| Połączenie kilku serwisów | Decyzja, które treści zachować i gdzie je przenieść | Duplikacja, kanibalizacja i błędne redirecty |
Jeśli istnieje stara strona, przed zmianami trzeba wyeksportować jej adresy z crawlów, Google Search Console, analityki, map XML, systemu CMS i narzędzia do analizy linków. Żadne pojedyncze źródło nie daje pewności, że lista jest kompletna.
Cele, odbiorcy i słowa kluczowe
Analiza słów kluczowych nie ma polegać na wstawieniu popularnych fraz do gotowych tekstów. Powinna określić, jakie podstrony w ogóle trzeba stworzyć i czego oczekuje użytkownik po wejściu.
Należy połączyć cztery perspektywy:
- biznesową - co firma chce sprzedawać i z jaką marżą,
- klienta - jaki problem, produkt lub lokalizację opisuje,
- wyszukiwarki - jaki typ strony dominuje w wynikach,
- konkurencji - gdzie istnieją luki możliwe do wykorzystania.
Każdej intencji należy przypisać jeden główny adres. Jeżeli kilka podstron próbuje odpowiadać na to samo zapytanie, nowa strona może zacząć z kanibalizacją. Jeżeli jedna podstrona obsługuje wiele odmiennych intencji, zwykle nie odpowiada dobrze na żadną.
Architektura informacji i mapa URL
Mapa strony powinna powstać przed makietami. Określa hierarchię, relacje między podstronami i wzorce adresów. Dla każdej pozycji warto zapisać cel, frazę główną, typ treści, status przygotowania i planowany URL.
| Typ strony | Cel | Przykładowy URL |
|---|---|---|
| Strona usługi | Zapytanie sprzedażowe | /oferta/pozycjonowanie-stron |
| Kategoria produktu | Porównanie grupy produktów | /sklep/meble-biurowe |
| Lokalizacja | Obsługa intencji lokalnej | /pozycjonowanie/szczecin |
| Poradnik | Odpowiedź informacyjna i przejście do oferty | /blog/audyt-seo-strony |
| Case study | Budowanie wiarygodności | /realizacje/nazwa-projektu |
Ważne strony nie powinny być ukryte kilka poziomów pod kategoriami ani dostępne wyłącznie z wyszukiwarki wewnętrznej. Menu, breadcrumbs, listingi i linki kontekstowe mają tworzyć logiczną drogę dla użytkownika i robota.
Treści potrzebne przed publikacją
Nie trzeba uruchamiać od razu ogromnego bloga. Trzeba natomiast opublikować kompletną podstawę: ofertę, informacje o firmie, kontakt, elementy zaufania oraz treści odpowiadające najważniejszym intencjom.
Każda strategiczna podstrona powinna mieć:
- jednoznaczny H1 i obietnicę wartości,
- odpowiedź na główną potrzebę bez zbędnego wstępu,
- zakres usługi lub produktu,
- proces, warunki, ograniczenia i kolejne kroki,
- dowody: realizacje, dane, opinie, certyfikaty lub eksperta,
- FAQ wynikające z rzeczywistych obiekcji klientów,
- czytelne wezwanie do działania,
- linki do stron pomagających kontynuować decyzję.
Teksty zastępcze, "lorem ipsum", robocze nagłówki i nieaktualne dane kontaktowe muszą zostać usunięte. Należy też sprawdzić prawa do zdjęć, spójność nazw firmy oraz poprawność informacji prawnych.
Adresy URL, canonical i wersje domeny
Adresy powinny być krótkie, opisowe i stabilne. Nie warto umieszczać w nich dat, losowych identyfikatorów ani struktury organizacyjnej, która może szybko się zmienić.
Przed publikacją ustal:
- wersję z www albo bez www,
- wymuszenie HTTPS,
- zasady małych liter, ukośników końcowych i parametrów,
- format adresów kategorii, produktów, usług i wpisów,
- canonical dla wszystkich indeksowalnych szablonów,
- hreflang dla wersji językowych, jeśli występują.
Wszystkie alternatywne warianty hosta i protokołu powinny prowadzić jednym przekierowaniem do wersji docelowej. Canonical nie zastępuje przekierowania i nie powinien wskazywać automatycznie na stronę główną.
Staging i ochrona wersji testowej
Wersja testowa nie powinna pojawić się w Google. Najpewniejszą ochroną jest uwierzytelnienie HTTP lub ograniczenie dostępu. Sam robots.txt nie usuwa strony z internetu i nie gwarantuje, że adres nie pojawi się w wynikach.
Jeżeli staging korzysta z noindex, trzeba wpisać usunięcie tej dyrektywy na krytyczną checklistę publikacji. Jednym z najczęstszych błędów jest skopiowanie ustawień testowych na produkcję i zablokowanie całego serwisu.
Przed go-live wykonaj pełny crawl środowiska testowego. Po publikacji wykonaj drugi crawl produkcji i porównaj statusy, canonicale, noindex, nagłówki oraz linki.
Indeksowanie, robots.txt i mapa XML
Przed uruchomieniem trzeba ustalić, które typy adresów mają znaleźć się w Google, a które powinny pozostać poza indeksem. Nie każda technicznie dostępna strona zasługuje na indeksowanie.
- robots.txt nie może blokować ważnych zasobów i podstron,
- indeksowalne strony nie mogą mieć noindex,
- mapa XML powinna zawierać wyłącznie docelowe adresy 200,
- adresy w sitemapie, canonicalach i linkach muszą być spójne,
- wyniki wyszukiwarki wewnętrznej i techniczne parametry zwykle nie powinny trafiać do indeksu,
- strona 404 powinna zwracać kod 404, nie 200.
Mapę XML zgłasza się w Google Search Console po publikacji. Nie trzeba ręcznie wysyłać każdego adresu. Ważniejsze jest poprawne linkowanie, dostępność oraz spójna architektura.
Migracja oraz przekierowania 301
Jeżeli strona zastępuje istniejący serwis, każdy stary wartościowy URL musi mieć decyzję: pozostaje bez zmian, przekierowuje do najbliższego odpowiednika, jest scalany albo celowo zwraca 404/410.
Nie przekierowuj wszystkich usuniętych stron na homepage. Adres produktu powinien prowadzić do następcy albo najbardziej zbliżonej kategorii. Artykuł powinien prowadzić do treści odpowiadającej tej samej intencji.
| Stary URL | Nowy URL | Decyzja | Kontrola |
|---|---|---|---|
| /stara-usluga | /oferta/nowa-usluga | 301 - zgodny odpowiednik | Status i brak łańcucha |
| /blog/stary-poradnik | /blog/nowy-poradnik | 301 po scaleniu treści | Zachowana intencja |
| /produkt-wycofany | /kategoria | 301 tylko przy realnym odpowiedniku | Przydatność dla użytkownika |
| /spamowy-url | - | 404 lub 410 | Brak wartości i linków |
Stare przekierowania również trzeba przenieść. Nowa reguła nie powinna tworzyć wieloetapowego łańcucha. Linki wewnętrzne, canonicale i sitemapę aktualizuje się bezpośrednio do adresów docelowych.
SEO on-page przed uruchomieniem
Każdy indeksowalny szablon trzeba sprawdzić pod kątem:
- unikalnego i opisowego title,
- jednego głównego H1,
- logicznej hierarchii H2 i H3,
- meta description zachęcającego właściwą osobę do wejścia,
- tekstu alternatywnego dla obrazów przekazujących informację,
- linków wewnętrznych i poprawnych anchorów,
- breadcrumbs,
- Open Graph dla udostępnień,
- unikalnej, kompletnej treści.
Limity znaków są wskazówką, nie prawem. Najważniejsze jest jasne znaczenie i dopasowanie do zapytania. System CMS powinien pozwalać edytować te elementy bez ingerencji programisty.
Dane strukturalne i wyniki rozszerzone
Schema.org należy dobrać do rzeczywistej zawartości. Typowe wdrożenia obejmują Organization lub LocalBusiness, BreadcrumbList, Product, Article, Event i ProfilePage. Dane muszą być zgodne z tym, co użytkownik widzi na stronie.
Kod trzeba sprawdzić walidatorem i przetestować na produkcji. Sam brak błędu nie gwarantuje wyświetlenia wyniku rozszerzonego. Schema pomaga opisać zawartość, ale nie zastępuje wartościowej treści ani poprawnego indeksowania.
Szybkość i Core Web Vitals
Wersję testową należy zbadać przed publikacją, ale rzeczywiste dane użytkowników pojawią się dopiero po zgromadzeniu ruchu na produkcji. Trzeba połączyć testy laboratoryjne z późniejszym monitoringiem danych terenowych.
- kompresuj i skaluj obrazy do realnego miejsca wyświetlania,
- nie opóźniaj kluczowego obrazu hero bez potrzeby,
- ogranicz ciężkie skrypty, widżety i biblioteki,
- ustaw właściwe ładowanie fontów,
- rezerwuj przestrzeń dla obrazów i elementów dynamicznych,
- stosuj cache i CDN, jeśli projekt tego wymaga,
- sprawdź wydajność na słabszym telefonie i wolniejszym łączu.
Testuj reprezentatywne szablony: stronę główną, usługę, artykuł, kategorię, produkt i koszyk. Dobry wynik homepage nie oznacza, że cały serwis jest szybki.
Mobile, dostępność i UX
Google korzysta z mobilnej wersji treści do indeksowania, ale ważniejszy jest klient, który nie potrafi kliknąć przycisku, przeczytać tabeli albo wypełnić formularza. Należy sprawdzić różne rozdzielczości, orientacje i urządzenia.
Kontrola obejmuje:
- czytelność tekstu i kontrast,
- widoczne stany fokusu oraz obsługę klawiaturą,
- etykiety formularzy i komunikaty błędów,
- wielkość obszarów klikalnych,
- brak poziomego przewijania,
- poprawne menu i wyszukiwarkę,
- treść oraz linki dostępne także bez efektów hover,
- brak natrętnych popupów zasłaniających główną zawartość.
Analityka, konwersje i zgody
Analitykę trzeba zaplanować przed startem, aby nie stracić danych z pierwszych dni. Samo zainstalowanie narzędzia nie oznacza poprawnego pomiaru.
Przygotuj:
- Google Search Console dla wszystkich potrzebnych właściwości,
- narzędzie analityczne i menedżer tagów,
- zdarzenia dla formularzy, telefonów, e-maili, zakupów i rezerwacji,
- wartości oraz waluty dla e-commerce,
- wykluczenie ruchu wewnętrznego i testowego,
- integrację z CRM, jeśli lead ma długi cykl sprzedaży,
- mechanizm zgód zgodny z wymaganiami prawnymi i działaniem tagów.
Po publikacji wykonaj rzeczywistą konwersję testową i sprawdź cały przepływ: przeglądarka, analityka, wiadomość e-mail, CRM i podziękowanie. Kliknięcie przycisku nie zawsze oznacza skuteczne przesłanie danych.
Formularze, e-commerce i testy funkcjonalne
SEO nie ma wartości, jeżeli strona zdobywa ruch, ale nie pozwala skontaktować się lub kupić. Testy powinny objąć scenariusze poprawne i błędne.
- formularze, walidację, autorespondery i dostarczenie wiadomości,
- numery telefonu oraz adresy e-mail,
- wyszukiwarkę i filtry,
- koszyk, płatności, dostawę, rabaty i faktury,
- zakładanie konta i reset hasła,
- brak towaru i wycofany produkt,
- strony 404 i 500,
- linki, pliki do pobrania i integracje zewnętrzne.
Przed premierą wykonaj backup i przygotuj plan wycofania wdrożenia. Właściciel projektu powinien wiedzieć, kto podejmuje decyzję o rollbacku, jeżeli wystąpi problem z zakupami, formularzami lub indeksowaniem.
Checklista dnia publikacji
| Kolejność | Kontrola | Kryterium zaliczenia |
|---|---|---|
| 1 | DNS, HTTPS i host docelowy | Jedna wersja domeny, ważny certyfikat, poprawne redirecty |
| 2 | Blokady stagingu | Produkcja bez noindex i bez blokady ważnych zasobów |
| 3 | Redirecty migracyjne | Stare URL-e prowadzą jednym 301 do właściwych stron |
| 4 | Crawl produkcji | Brak krytycznych 4xx/5xx, złych canonicali i osieroconych stron |
| 5 | Robots i sitemap | Spójne, dostępne i zawierające docelowe adresy |
| 6 | Formularze i zakup | Transakcja testowa dociera do systemów |
| 7 | Analityka | Odsłony i kluczowe zdarzenia są rejestrowane raz |
| 8 | Search Console | Zweryfikowana właściwość i przesłana mapa XML |
| 9 | Backup | Istnieje sprawdzona kopia i procedura przywracania |
Publikację najlepiej zaplanować wtedy, gdy zespół techniczny, SEO i osoba biznesowa są dostępne przez kolejne godziny. Piątkowy wieczór przed świętami to zły moment na relaunch serwisu generującego sprzedaż.
Pierwsze 30 dni po uruchomieniu
Wdrożenie nie kończy się po zmianie DNS. Pierwsze dni pokazują błędy niewidoczne na stagingu oraz reakcję wyszukiwarki na nową strukturę.
| Okres | Co monitorować? |
|---|---|
| Pierwsze 24 godziny | Dostępność, 5xx, formularze, płatności, redirecty, robots i noindex |
| Dni 2-7 | Indeksowanie, crawl GSC, 404, sitemapę, ruch i konwersje |
| Dni 8-14 | Zmiany zapytań i landing page'y, błędy redirectów, logi i wydajność |
| Dni 15-30 | Widoczność, jakość ruchu, konwersję, Core Web Vitals i priorytety poprawek |
Wahania po większej migracji są możliwe. Nie każda zmiana oznacza katastrofę, ale nagłe zniknięcie ważnych adresów, spadek crawlowania lub gwałtowny wzrost 404 wymaga szybkiej diagnozy.
Najczęstsze błędy
| Błąd | Skutek | Jak zapobiec? |
|---|---|---|
| SEO dopiero po projekcie | Brak potrzebnych szablonów i zła architektura | Research przed makietami |
| Zmiana wszystkich URL-i | Ryzyko utraty pozycji i linków | Zachować dobre adresy lub mapować 1:1 |
| Brak redirectów 301 | 404 i utrata sygnałów starej strony | Mapa migracji testowana przed startem |
| Noindex na produkcji | Strona nie może wejść do indeksu | Crawl i kontrola nagłówków po wdrożeniu |
| Wszystkie 404 na homepage | Niedopasowane redirecty i soft 404 | Najbliższy odpowiednik albo uczciwe 404 |
| Publikacja bez treści | Puste podstrony i słaba użyteczność | Minimum contentowe przed go-live |
| Brak analityki | Brak punktu odniesienia i danych o sprzedaży | Test pomiaru przed kampaniami |
| Brak monitoringu | Problemy trwają tygodniami | Plan kontroli na 1, 7, 14 i 30 dzień |
Planujesz nową stronę i nie chcesz stracić widoczności?
Sprawdzimy architekturę, makiety, treści i plan wdrożenia przed publikacją. Jeśli zastępujesz istniejący serwis, przygotujemy mapę migracji oraz kontrolę po uruchomieniu.
Zarezerwuj darmową konsultację SEONajczęstsze pytania
Kiedy rozpocząć SEO nowej strony?
Przed przygotowaniem architektury i makiet. Analiza popytu powinna określić podstrony, szablony, nazwy kategorii, adresy i wymagania dla CMS.
Czy nową stronę trzeba zgłosić do Google?
Warto zweryfikować domenę w Google Search Console i przesłać mapę XML. Google może odkryć stronę także przez linki, ale Search Console ułatwia kontrolę indeksowania i błędów.
Czy zmiana strony zawsze powoduje spadek pozycji?
Nie. Krótkie wahania są możliwe, ale prawidłowo przygotowana migracja może zachować widoczność. Największe ryzyko tworzą zmiany URL-i bez redirectów, usunięcie treści i błędy indeksowania.
Czy można zablokować stronę testową w robots.txt?
Robots.txt ogranicza crawlowanie, ale nie jest pewnym zabezpieczeniem przed pojawieniem się URL-a w wynikach. Staging najlepiej chronić uwierzytelnieniem lub ograniczeniem dostępu.
Jak długo powinny działać przekierowania 301?
W praktyce warto utrzymywać je długoterminowo, szczególnie dla adresów mających ruch lub linki. Ich zbyt szybkie usunięcie może ponownie tworzyć błędy 404.
Czy trzeba mieć blog w dniu uruchomienia?
Nie trzeba publikować wielu artykułów. Ważniejsze są kompletne strony usług, produktów i informacji o firmie. Blog można rozwijać według zaplanowanych klastrów po premierze.
SEO przed premierą kosztuje mniej niż ratowanie widoczności po niej.
Dobrze przygotowana strona nie musi być idealna w każdym detalu. Musi jednak mieć poprawny fundament: logiczną strukturę, kompletne treści, stabilne adresy, dostępność dla wyszukiwarki, pomiar celów oraz procedurę kontroli.
Jeśli zastępuje istniejący serwis, musi dodatkowo chronić to, co już działa. Historia URL-i, linki i treści nie znikają tylko dlatego, że nowy design wygląda lepiej.
Najlepszy moment na znalezienie błędu migracji jest przed publikacją. Drugi najlepszy - w pierwszych minutach po niej, zanim problem zacznie kosztować ruch i klientów.
