Technical SEO – 10 błędów, które kosztują Cię pozycje

Dlaczego to problem?

robots.txt to pierwsza rzecz, po którą sięga Googlebot, gdy wpada na Twoją stronę. Zablokujesz tu przez przypadek ważne zasoby – i Google ich po prostu nie zobaczy.

A czego Google nie widzi, tego dla wyszukiwarki nie ma. Koniec, kropka.

Najczęstsze scenariusze, na które się natykam:

• Disallow: / – zablokowana cała strona (klasyk zostawiony po etapie deweloperskim)
• blokada katalogów CSS/JS – Google nie ma jak zrenderować strony
• blokada katalogów ze zdjęciami – obrazy nie wpadają do Google Images
• reguły z wildcardami, które łapią więcej, niż się komukolwiek śniło

Jak zdiagnozować?

Zacznij od najprostszego: wpisz w przeglądarce twojadomena.pl/robots.txt i zobacz, co tam siedzi.

Potem zajrzyj do Google Search Console → Ustawienia → Plik robots.txt – pokaże dokładnie to, co widzi sam Google, a nie to, co Ci się wydaje.

W Screaming Frog puść crawl i rzuć okiem na kolumnę „Indexability" – strony ucięte przez robots.txt od razu rzucą się w oczy.

User-agent: *
Allow: /
Disallow: /admin/
Disallow: /cart/
Disallow: /checkout/
Disallow: /search?

Sitemap: https://twojadomena.pl/sitemap.xml

Jak naprawić?

1. Sprawdź aktualny plik robots.txt
2. Upewnij się, że nie blokujesz CSS, JS ani obrazów
3. Usuń regułę Disallow: /, jeśli strona jest gotowa do indeksacji
4. Dodaj ścieżkę do sitemap.xml
5. Przetestuj w Google Search Console → Tester robots.txt

Dlaczego to problem?

Mapa witryny (sitemap.xml) to po prostu lista adresów, które chcesz mieć w indeksie Google. Bez niej Googlebot musi sam wydeptać ścieżki do Twoich podstron przez linkowanie wewnętrzne. W praktyce wygląda to tak: nowe albo słabo podlinkowane strony lądują w indeksie z potężnym opóźnieniem – albo nie lądują wcale.

Częste wpadki w mapach witryny:

• adresy zwracające 404, 301 albo z tagiem noindex
• adresy z innej domeny lub protokołu (http zamiast https)
• przekroczony limit 50 000 adresów / 50 MB na jeden plik
• mapa, której nikt nie zgłosił w Google Search Console

Jak zdiagnozować?

Wejdź na twojadomena.pl/sitemap.xml i zobacz, czy w ogóle istnieje i czy są w niej aktualne adresy. Potem w Google Search Console → Mapy witryn sprawdzisz status przetwarzania i liczbę wykrytych adresów.

Jak naprawić?

1. Wygeneruj mapę automatycznie – wtyczką SEO, frameworkiem albo generatorem
2. Zostaw w niej wyłącznie kanoniczne adresy 200 OK, indeksowalne
3. Duże serwisy podziel na mapy tematyczne i spnij je przez sitemap index
4. Wskaż mapę w robots.txt i zgłoś ją w Search Console

Mapa witryny to nie śmietnik na wszystko, co masz. To krótka lista stron, które naprawdę chcesz widzieć w Google.

Dlaczego to problem?

Wyobraź sobie, że ta sama treść siedzi pod kilkoma adresami naraz – z parametrami filtrowania, w wersji z www i bez, ze slashem na końcu i bez niego. Google staje wtedy przed pytaniem: którą wersję w ogóle pokazać? I zamiast jednej mocnej strony masz kilka słabszych – rozproszona moc linków, kanibalizacja, przepalony budżet crawlowania.

Canonical to Twój sposób, żeby powiedzieć Google wprost: „ta wersja jest tą właściwą". Bez tego zgaduje za Ciebie – i nie zawsze trafia.

Jak zdiagnozować?

W Search Console → Strony wypatruj statusów „Duplikat" oraz „Alternatywna strona z właściwym tagiem kanonicznym". Screaming Frog z kolei wyłapie zdublowane tytuły i treści oraz brakujące canonical.

<link rel="canonical" href="https://twojadomena.pl/produkt" />

Jak naprawić?

1. Ustaw self-referencing canonical na każdej kanonicznej stronie
2. Wybierz jedną wersję domeny (https z www lub bez) i przekieruj resztę przez 301
3. Ujednolić adresy z parametrami – canonical kieruj do wersji bazowej
4. Nie mieszaj canonical z noindex na tej samej stronie – to sprzeczne sygnały

Dlaczego to problem?

Szybkość to czynnik rankingowy, ale – szczerze? – jeszcze bardziej jest czynnikiem konwersji. Wolna strona traci klientów, zanim Google w ogóle wejdzie do gry. Core Web Vitals opisują realne odczucia użytkownika trzema liczbami:

• LCP (Largest Contentful Paint) – czas wczytania głównej treści, cel < 2,5 s
• INP (Interaction to Next Paint) – responsywność, cel < 200 ms
• CLS (Cumulative Layout Shift) – stabilność układu, cel < 0,1

Jak zdiagnozować?

Sięgnij po PageSpeed Insights (dane laboratoryjne i polowe), raport Core Web Vitals w Search Console oraz zakładkę Lighthouse w Chrome DevTools. Moja rada: patrz głównie na dane polowe – to one pokazują, jak stronę odbierają realni użytkownicy, a nie laboratorium.

Jak naprawić?

1. Kompresuj i serwuj obrazy w formatach WebP/AVIF, dodaj width/height
2. Włącz lazy-loading dla treści poniżej linii zgięcia
3. Minifikuj i odraczaj zbędny JavaScript, ogranicz zewnętrzne skrypty
4. Włącz cache i CDN, zarezerwuj miejsce na elementy (eliminacja CLS)

Dlaczego to problem?

Google ocenia strony w modelu mobile-first – czyli pod lupę bierze przede wszystkim wersję mobilną. Jeśli na telefonie tekst jest nieczytelny, przyciski mikroskopijne, a treść wyłazi poza ekran, tracisz i pozycje, i klientów. A mówimy o ponad połowie ruchu.

Dla Google Twoja strona to przede wszystkim ta na telefonie. Desktop jest dziś dodatkiem, nie odwrotnie.

Jak zdiagnozować?

Odpal Chrome DevTools w trybie urządzenia, przejdź test optymalizacji mobilnej i zerknij na raport „Obsługa na urządzeniach mobilnych" w Search Console. I najważniejsze – weź telefon do ręki i poklikaj po stronie jak normalny człowiek. Żadne narzędzie tego nie zastąpi.

Jak naprawić?

1. Stosuj responsywny layout (RWD) zamiast osobnej domeny mobilnej
2. Dodaj poprawny <meta name="viewport">
3. Cele dotykowe min. 48×48 px, czytelna typografia (≥16 px)
4. Ta sama treść i dane strukturalne na mobile i desktop

Dlaczego to problem?

Tag noindex to dla Google jasny komunikat: „tej strony nie pokazuj w wynikach". Problem w tym, że potrafi wskoczyć na ważne podstrony przez przypadek – po migracji albo globalnie z poziomu motywu – i po cichu wymiata je z indeksu. nofollow z kolei zakręca kurek z mocą linków.

Jeden zabłąkany noindex potrafi narobić więcej szkód niż dziesięć słabych tekstów. I jest cichy – nic nie wybucha, ruch po prostu znika.

Jak zdiagnozować?

W Search Console szukaj statusu „Wykluczona przez tag noindex", a w Screaming Frog odpal filtr Directives → Noindex. Nie zapomnij o nagłówku HTTP X-Robots-Tag – działa dokładnie tak samo jak meta, a łatwo go przeoczyć, bo nie widać go w kodzie strony.

Jak naprawić?

1. Usuń noindex ze stron, które mają rankować
2. Zostaw go świadomie tylko na koszyku, logowaniu, podziękowaniach itp.
3. Sprawdź ustawienia CMS „odradzaj wyszukiwarkom indeksowania"
4. Po poprawce użyj „Sprawdź URL → Poproś o zindeksowanie"

Dlaczego to problem?

Każde przekierowanie to dodatkowy skok i ciut utraconej mocy. A teraz wyobraź sobie łańcuch: A → B → C → D. Strona zwalnia, crawlowanie się męczy, a moc rozmywa się po drodze. Do tego użycie 302 (tymczasowe) tam, gdzie powinno stać 301 (trwałe), sprawia, że Google nie przekazuje pełnej mocy na nowy adres.

Jak zdiagnozować?

Screaming Frog → raport Redirect Chains rozrysuje Ci całe łańcuchy i pętle jak na dłoni. Warto też zerknąć na kody odpowiedzi w logach serwera albo w narzędziu typu Redirect Path.

Jak naprawić?

1. Skróć łańcuchy do jednego skoku – z A prosto na D
2. Stosuj 301 przy zmianach trwałych, 302 zostaw na to, co naprawdę tymczasowe
3. Podmień linki wewnętrzne tak, żeby celowały od razu w docelowy adres
4. Wytęp pętle przekierowań i przekierowania prowadzące do 404

Dlaczego to problem?

Dane strukturalne (Schema.org) pomagają Google rozszyfrować kontekst Twojej treści – i odblokowują rich snippets: gwiazdki ocen, ceny, FAQ, breadcrumbs, przepisy. Brzmi banalnie? A jednak to one robią różnicę: wynik w SERP staje się większy i bardziej klikalny, więc przy tej samej pozycji wyciągasz wyższy CTR.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Technical SEO – 10 błędów",
  "author": { "@type": "Person", "name": "Sebastian Baryś" }
}
</script>

Jak naprawić?

1. Dobierz typy schema do treści (Article, Product, FAQPage, LocalBusiness…)
2. Wdróż je w formacie JSON-LD – to format rekomendowany przez Google
3. Sprawdź wynik w teście elementów rozszerzonych i w Schema Markup Validator
4. Nie oznaczaj treści, której na stronie nie ma – to prosta droga do kary

Dlaczego to problem?

Gdy kluczowa treść albo linki pojawiają się dopiero po odpaleniu JavaScriptu – co jest chlebem powszednim w SPA na React, Vue czy Angularze – Google musi przejść przez kosztowny etap renderowania. I bywa różnie: czasem treść nie trafia do indeksu w ogóle, a czasem ląduje tam z solidnym opóźnieniem.

Jeśli treść widać dopiero po wykonaniu JS, to dla Google jest ona w najlepszym razie „na później". A „na później" w SEO często znaczy „nigdy".

Jak zdiagnozować?

W Search Console wejdź w Sprawdź URL → Przetestuj URL na żywo → Zrzut ekranu / HTML i zobacz, co Google naprawdę wyrenderował. Dobry trik: wyłącz JavaScript w przeglądarce i porównaj surowy kod źródłowy z wyrenderowanym DOM. Różnice powiedzą Ci wszystko.

Jak naprawić?

1. Stosuj SSR lub SSG (np. Astro, Next.js) dla treści krytycznej dla SEO
2. Alternatywnie dynamic rendering / prerendering dla botów
3. Linki jako prawdziwe <a href>, nie zdarzenia onClick
4. Nie blokuj plików JS/CSS w robots.txt

Dlaczego to problem?

HTTPS to potwierdzony czynnik rankingowy i po prostu podstawa zaufania. Strona bez certyfikatu SSL dostaje od przeglądarki łatkę „niezabezpieczona" – a to skutecznie odstrasza odwiedzających i podbija współczynnik odrzuceń. Na dokładkę treści mieszane (mixed content) psują i bezpieczeństwo, i wygląd strony.

Jak zdiagnozować?

Spójrz na kłódkę w pasku adresu i sprawdź ważność certyfikatu. W DevTools → Console wyskoczą ostrzeżenia o mixed content. I upewnij się, że http przekierowuje przez 301 na https – to częsty pominięty detal.

Jak naprawić?

1. Zainstaluj certyfikat SSL – często jest darmowy, choćby Let's Encrypt
2. Wymuś 301 z http na https i ujednolić wersję z www / bez www
3. Przestaw wszystkie zasoby na https i pożegnaj się z mixed content
4. Zaktualizuj canonical, sitemap oraz adres w Search Console