Techniczne SEO dla firmy software – co ma znaczenie

W technicznym SEO strony firmy software najważniejsze jest to, czy właściwe podstrony – usługi, case studies i artykuły eksperckie – są pobierane, indeksowane i poprawnie rozumiane przez wyszukiwarki i systemy AI. Wszystko inne jest wtórne. Dlatego zamiast listy ogólnych porad poniżej znajdziesz checklistę audytu w kolejności, w jakiej przechodzimy ją w praktyce: od indeksacji, przez canonicale, hreflang i mapy witryny, po Core Web Vitals, dane strukturalne i analizę logów. Jak budować widoczność treścią i architekturą informacji, opisujemy w osobnym wpisie techniczne SEO dla firmy software – jak budować widoczność.

Krok 0: przygotowanie audytu

Zanim zaczniesz, zbierz:

• dostęp do Google Search Console (usługa domeny, nie tylko prefiks URL) i do Bing Webmaster Tools,
• listę kluczowych adresów: strona główna, strony usług, case studies, najważniejsze artykuły,
• crawler, który przejdzie całą stronę jak robot (np. Screaming Frog lub podobne narzędzie),
• dostęp do logów serwera lub CDN, jeśli to możliwe.

Na koniec audytu każdy problem powinien mieć priorytet i właściciela. Lista 200 ostrzeżeń bez kolejności niczego nie zmieni.

Krok 1: indeksacja

1. Otwórz w Search Console raport Strony (indeksowanie stron) i sprawdź, które adresy są wykluczone i dlaczego.
2. Zwróć uwagę na statusy „Strona zeskanowana, ale obecnie nie zindeksowana” i „Wykryto – obecnie nie zindeksowano”. Jeżeli dotyczą stron usług, to sygnał, że Google nie uważa ich za wystarczająco wartościowe albo nie może do nich dotrzeć.
3. Sprawdź kluczowe adresy narzędziem Sprawdzanie adresu URL – czy strona jest zindeksowana, jaki canonical wybrał Google i jak wygląda wyrenderowany HTML.
4. Przejrzyj robots.txt: czy nie blokuje zasobów potrzebnych do renderowania (CSS, JS) i czy nie blokuje stron, które mają być widoczne. Pamiętaj, że robots.txt nie usuwa strony z indeksu – do tego służy noindex.
5. Wyszukaj w crawlu przypadkowe noindex – częsty efekt przeniesienia ustawień ze środowiska testowego na produkcję.
6. Upewnij się, że środowisko testowe jest zabezpieczone hasłem, a nie tylko noindexem.

Krok 2: adresy URL i canonicale

• Każda strona powinna mieć jeden kanoniczny adres: z ukośnikiem na końcu albo bez, zawsze przez HTTPS, z jedną wersją domeny.
• Sprawdź, czy wersje alternatywne przekierowują 301, a nie zwracają 200 z tą samą treścią.
• Canonical powinien wskazywać adres, który zwraca 200, nie przekierowuje i nie ma noindex.
• Parametry (UTM, sortowanie, filtry na blogu) nie mogą tworzyć tysięcy duplikatów w indeksie.
• Paginacja bloga: każda strona listy ma własny canonical wskazujący na siebie, a nie na pierwszą stronę. Google nie używa już znaczników rel="prev/next" jako sygnału.
• Porównaj canonical deklarowany z wybranym przez Google w Search Console. Rozbieżność zwykle oznacza duplikację treści lub sprzeczne sygnały.

Krok 3: hreflang i wersje językowe

Firmy software często mają stronę po polsku, angielsku i niemiecku. Wtedy sprawdź:

• czy każda wersja językowa wskazuje wszystkie odpowiedniki, łącznie z samą sobą,
• czy powiązania są zwrotne – jeśli strona PL wskazuje EN, strona EN musi wskazywać PL,
• czy kody są poprawne (np. `pl`, `en`, `de` albo `de-AT`, a nie `en-UK`),
• czy istnieje `x-default` dla użytkowników spoza obsługiwanych języków,
• czy hreflang wskazuje kanoniczne adresy, a nie przekierowania,
• czy strona nie przekierowuje automatycznie na podstawie adresu IP lub języka przeglądarki – robot może wtedy nie zobaczyć innych wersji.

Krok 4: mapy witryny

• Sitemap zawiera tylko adresy kanoniczne, zwracające 200 i przeznaczone do indeksacji.
• `lastmod` odpowiada rzeczywistej dacie istotnej zmiany treści, a nie dacie wygenerowania pliku. Google ignoruje pola `priority` i `changefreq`.
• Mapa jest zgłoszona w Search Console i wskazana w robots.txt.
• Porównaj liczbę adresów w mapie z liczbą zindeksowanych – duża różnica wymaga wyjaśnienia.
• Nowe artykuły i case studies pojawiają się w mapie automatycznie po publikacji.

Krok 5: Core Web Vitals i wydajność

Google ocenia doświadczenie strony na podstawie danych od realnych użytkowników (raport w Search Console i dane CrUX). Progi „dobrego” wyniku dla 75. percentyla wizyt to:

• LCP (największe wyrenderowanie treści) – do 2,5 s,
• INP (interakcja do następnego wyrenderowania) – do 200 ms; od marca 2024 roku zastąpił FID,
• CLS (przesunięcia układu) – do 0,1.

Na stronach firmowych najczęstsze przyczyny złych wyników to ciężkie obrazy w pierwszym ekranie, fonty ładowane bez `font-display`, skrypty marketingowe i czaty ładowane synchronicznie oraz animacje, które blokują główny wątek. Po stronie serwera sprawdź cache stron publicznych i czas odpowiedzi (TTFB). Publiczne widoki nie powinny bez potrzeby tworzyć sesji ani ustawiać nagłówków, które blokują cache.

Krok 6: dane strukturalne

• Organization na stronie głównej – nazwa, logo, adres, profile firmy.
• BreadcrumbList na podstronach.
• Article lub BlogPosting na wpisach – autor, data publikacji i aktualizacji.
• Service lub opisowe dane na stronach usług, zgodne z widoczną treścią.
• Walidacja w Rich Results Test i w raportach ulepszeń Search Console.

Znaczniki FAQPage nie dadzą już rozszerzonych wyników w Google na zwykłej stronie firmowej – od 2023 roku są one pokazywane głównie dla serwisów rządowych i medycznych. Dane strukturalne muszą zawsze odpowiadać temu, co widzi użytkownik.

Krok 7: logi serwera

Logi pokazują, co roboty faktycznie pobierają, a nie tylko to, co deklaruje mapa witryny. Sprawdź:

• jak często Googlebot odwiedza strony usług w porównaniu z tagami, archiwami i parametrami,
• czy roboty trafiają na błędy 404 i 5xx albo łańcuchy przekierowań,
• czy nowe treści są pobierane w rozsądnym czasie po publikacji,
• które roboty AI odwiedzają stronę (np. GPTBot, OAI-SearchBot, PerplexityBot) i czy reguły w robots.txt są zgodne z decyzją firmy o dostępie do treści.

Ruch podszywający się pod Googlebota weryfikuj przez odwrotne zapytanie DNS, a nie tylko po nagłówku User-Agent.

Krok 8: linkowanie wewnętrzne i strony osierocone

• Każda strona usługi powinna mieć linki z menu, z powiązanych artykułów i z case studies.
• Wyszukaj strony osierocone – obecne w mapie witryny, ale bez linków wewnętrznych.
• Sprawdź głębokość kliknięć: kluczowe strony nie powinny być dalej niż kilka kliknięć od strony głównej.
• Popraw linki prowadzące do przekierowań.

Wynik audytu: jak ustalić priorytety

Podziel znalezione problemy na trzy grupy:

1. Blokujące – noindex na stronach usług, błędne canonicale, niedostępne zasoby. Naprawiane od razu.
2. Istotne – słabe Core Web Vitals, błędy hreflang, strony osierocone. Planowane w najbliższym sprincie.
3. Porządkowe – drobne błędy danych strukturalnych, pojedyncze przekierowania. Zbierane i naprawiane w pakiecie.

Po wdrożeniu poprawek porównaj dane przed i po – jak zaplanować taki pomiar, piszemy w artykule jak mierzyć efekty nowej strony firmowej.

Następny krok

Zacznij od kroków 1 i 2 – indeksacji i canonicali dla stron usług. To zajmuje najmniej czasu, a najczęściej ujawnia problemy, które blokują resztę działań. Jeśli chcesz, żebyśmy przeprowadzili pełny audyt i przygotowali listę poprawek z priorytetami, sprawdź usługę widoczność w AI i SEO albo napisz do nas.