Projektowanie strony pod SEO powinno rozpocząć się przed przygotowaniem makiet. Jeśli struktura oferty, adresy i wymagania CMS powstają dopiero po zaakceptowaniu projektu graficznego, część zmian wymaga przebudowy nawigacji, szablonów albo bazy danych.
SEO nie oznacza rezygnacji z atrakcyjnego projektu. Chodzi o ustalenie, jakie informacje ma znaleźć użytkownik, jak przejdzie od problemu do oferty oraz czy wyszukiwarka będzie mogła pobrać, zinterpretować i zaindeksować potrzebne strony.
Zacznij od celów biznesowych i odbiorców
Lista planowanych zakładek nie powinna wynikać wyłącznie ze struktury starej witryny. Najpierw trzeba ustalić:
- które usługi lub produkty mają największe znaczenie,
- jakich klientów firma chce pozyskiwać,
- jakie problemy poprzedzają kontakt,
- jak wygląda decyzja zakupowa,
- które działania na stronie będą mierzone,
- jakie treści i materiały firma rzeczywiście może przygotować.
Przykładowo osobne strony usług są uzasadnione wtedy, gdy odpowiadają na odrębne potrzeby i mają własny zakres. Tworzenie kilkunastu prawie identycznych podstron tylko dlatego, że istnieją podobne frazy, prowadzi do duplikacji i problemu z wyborem właściwego URL-a.
Badanie słów kluczowych powinno poprzedzać makiety
Dane z GSC, Planera, rozmów sprzedażowych i wyników wyszukiwania pomagają określić, jakiego typu stron potrzebuje serwis. Wynikiem nie powinna być lista słów do umieszczenia w stopce, ale mapa intencji i adresów.
Dla każdego ważnego tematu trzeba wskazać:
- typ strony: oferta, kategoria, produkt, poradnik lub lokalizacja,
- główną potrzebę użytkownika,
- planowany URL,
- miejsce w nawigacji,
- materiały wymagane do publikacji,
- konwersję albo następny krok.
Proces ten opisuję szerzej w poradniku o doborze słów kluczowych.
Jak zaprojektować architekturę informacji?
Struktura powinna pozwalać przejść od ogólnej sekcji do konkretnej usługi lub produktu. Nie należy traktować menu jako listy wszystkich URL-i. Rozbudowany serwis potrzebuje stron nadrzędnych, kategorii i logicznych połączeń między materiałami.
Przy projektowaniu sprawdź:
- Czy każda ważna usługa ma właściwą stronę docelową?
- Czy użytkownik rozumie różnicę między podobnymi ofertami?
- Czy kategorie zawierają zwykłe linki do podkategorii i produktów?
- Czy poradniki prowadzą do właściwych usług?
- Czy żadna kluczowa strona nie jest dostępna wyłącznie przez wyszukiwarkę wewnętrzną?
- Czy struktura pozwala dodać nowe treści bez przebudowy menu?
Adresy URL powinny być czytelne i stabilne. Nie warto wprowadzać daty, identyfikatora technologicznego ani niepotrzebnie rozbudowanej ścieżki, jeśli utrudni to przyszłe zmiany.
Wymagania SEO dla systemu CMS
Decyzja o wyborze CMS-a powinna uwzględniać sposób zarządzania treścią, a nie jedynie wygląd panelu. Redaktor powinien móc kontrolować:
- tytuł strony i meta description,
- jeden główny nagłówek H1,
- strukturę nagłówków w treści,
- adres URL,
- canonical,
- dyrektywę index lub noindex,
- przekierowania po zmianie adresu,
- tekst alternatywny obrazów,
- elementy nawigacji i breadcrumbs,
- dane uporządkowane właściwe dla typu strony,
- mapę witryny XML.
Nie wszystkie pola muszą być ręcznie edytowane na każdej stronie. Dla produktów lub lokalizacji część danych może pochodzić z szablonu. Trzeba jednak wiedzieć, jakie reguły generują wartości i jak obsłużyć wyjątek.
Projekt komponentów, a nie tylko pojedynczych ekranów
Makieta powinna uwzględniać rzeczywistą długość treści. Nagłówek, opis usługi, tabela, formularz, opinie i sekcja pytań muszą działać zarówno przy krótkim, jak i dłuższym materiale.
Projektant powinien przygotować zachowanie komponentów na telefonie, stan błędu formularza, brak zdjęcia, długą nazwę produktu i większą liczbę wariantów. Pominięcie tych sytuacji prowadzi do ręcznych obejść po uruchomieniu serwisu.
Warto też ustalić, które elementy są częścią treści strony, a które dekoracją. Tekst umieszczony wyłącznie w grafice nie jest dobrym sposobem prezentowania podstawowego zakresu usługi, ceny ani parametrów produktu.
JavaScript i możliwość znalezienia treści
Nowoczesny interfejs może wykorzystywać JavaScript, ale kluczowe treści i linki muszą być dostępne w wyrenderowanej stronie. Nawigacja powinna używać prawidłowych odnośników z atrybutem href.
Szczególną uwagę trzeba zwrócić na:
- treści wczytywane dopiero po kliknięciu,
- produkty dostępne wyłącznie przez filtrowanie,
- paginację i przewijanie nieskończone,
- wersje językowe,
- linki obsługiwane wyłącznie zdarzeniem skryptu,
- renderowanie metadanych po stronie przeglądarki.
Oceny nie należy opierać wyłącznie na tym, co widzi użytkownik w przeglądarce. Trzeba sprawdzić kod oraz wyrenderowaną wersję dostępną dla Google.
Szybkość jako wymaganie projektowe
Problemu z wydajnością nie zawsze da się rozwiązać przez późniejsze zmniejszenie obrazów. Na wynik wpływają również liczba skryptów, krój i sposób ładowania fontów, animacje, banery, integracje zewnętrzne, serwer oraz sposób generowania strony.
Przed wdrożeniem warto ustalić budżet wydajnościowy, np. maksymalną masę obrazu głównego, liczbę używanych fontów i zasady dodawania skryptów zewnętrznych. Pomiary trzeba wykonywać na reprezentatywnych szablonach: stronie głównej, ofercie, kategorii, produkcie i artykule.
Szczegółową diagnostykę omawiam w materiale o Core Web Vitals i szybkości strony.
Jak zabezpieczyć środowisko testowe?
Wersja deweloperska nie powinna pojawiać się w wynikach wyszukiwania. Najpewniejszym zabezpieczeniem jest ograniczenie dostępu, np. uwierzytelnieniem. Dyrektywa noindex może być dodatkowym zabezpieczeniem, ale robot musi mieć możliwość pobrania strony, aby ją zobaczyć. Sam plik robots.txt nie chroni poufnej zawartości.
Przed publikacją należy sprawdzić, czy:
- usunięto blokadę dostępu z wersji produkcyjnej,
- ważne strony nie pozostały z dyrektywą noindex,
- robots.txt nie blokuje potrzebnych sekcji,
- canonical wskazuje produkcyjny adres,
- mapa XML zawiera właściwe URL-e,
- kody analityczne działają tylko w odpowiednim środowisku.
Migracja treści wymaga mapy adresów
Jeżeli nowa strona zastępuje istniejący serwis, projekt obejmuje również migrację. Przed uruchomieniem trzeba zestawić stare i nowe URL-e. Każdy wartościowy stary adres powinien otrzymać trafny odpowiednik.
Nie należy przekierowywać wszystkich usuniętych stron do strony głównej. Jeśli kilka materiałów zostało rzeczywiście połączonych w jeden, mogą kierować do wspólnej, skonsolidowanej strony. Jeśli nie istnieje odpowiednik, czasem poprawna odpowiedź 404 będzie uczciwsza niż nietrafne przekierowanie.
Google zaleca przy migracjach trwałe przekierowania HTTP 301 lub 308 i unikanie łańcuchów. Po wdrożeniu trzeba poprawić również linki wewnętrzne, canonicale i mapę witryny. Wybór nowej domeny warto poprzedzić analizą opisaną w poradniku o sprawdzaniu domeny.
Podział odpowiedzialności w projekcie
Brak właściciela zadania jest częstszym problemem niż brak zalecenia. Przed rozpoczęciem prac warto ustalić odpowiedzialność:
- właściciel firmy – cele, oferta, priorytety i akceptacja treści;
- SEO – analiza popytu, mapa URL-i, wymagania techniczne i plan migracji;
- UX oraz projektant – architektura interfejsu, komponenty i wersje mobilne;
- programista – szablony, renderowanie, przekierowania, wydajność i integracje;
- redaktor – przygotowanie oraz migracja treści i metadanych;
- analityk lub osoba wdrażająca pomiar – zdarzenia, konwersje i kontrola danych.
Jedna osoba może pełnić kilka ról, ale każde zadanie nadal powinno mieć wskazanego wykonawcę i kryterium odbioru.
Kontrola przed publikacją
- Przeskanuj wersję testową i sprawdź kody odpowiedzi.
- Zweryfikuj title, H1, canonicale oraz dyrektywy robots.
- Porównaj listę starych i nowych URL-i.
- Przetestuj przekierowania bez łańcuchów.
- Sprawdź menu, breadcrumbs i linkowanie w treści.
- Zweryfikuj formularze, telefony, koszyk i płatności.
- Przetestuj strony na telefonie i reprezentatywnych urządzeniach.
- Sprawdź mapę XML i robots.txt.
- Zweryfikuj dane uporządkowane.
- Zapisz stan ruchu, widoczności i konwersji przed uruchomieniem.
Co monitorować po wdrożeniu?
Bezpośrednio po publikacji należy sprawdzić działanie serwisu i przekierowań. W kolejnych dniach oraz tygodniach obserwuje się raport indeksowania, mapę witryny, błędy serwera, strony 404 i dane skuteczności w GSC.
Przy migracji mogą wystąpić tymczasowe wahania widoczności. Nie oznacza to, że każdy spadek należy przeczekać. Błędne przekierowania, pozostawione noindex albo canonicale prowadzące do wersji testowej wymagają natychmiastowej poprawy.
SEO przed wdrożeniem kosztuje mniej niż przebudowa
Projekt strony można skonsultować przed wykonaniem szablonów albo sprawdzić podczas audytu SEO. Jeżeli witryna jest już uruchomiona, zakres zmian ustalam w ramach optymalizacji strony.
Prześlij makiety, mapę adresów albo specyfikację na czesc@seomariusz.pl. Możesz też zadzwonić pod numer 665 015 610. Najwięcej problemów można usunąć wtedy, gdy zmiana nadal wymaga korekty dokumentacji, a nie gotowego systemu.
You must be logged in to post a comment.