Hiena SEO: model biznesowy oparty na tym, że klient ma się najpierw przestraszyć

W normalnej pracy technicznej kolejność jest nudna: zbieramy wymagania, sprawdzamy stan, reprodukujemy problem, mierzymy skalę, określamy ryzyko, proponujemy rozwiązanie, wdrażamy i testujemy. Hiena odwraca kolejność. Najpierw musi pojawić się emocja, a dopiero później technika.

Google w oficjalnym poradniku dla osób zatrudniających SEO zaleca pytać wykonawcę o sposób mierzenia wyników, zakres zmian i uzasadnienie rekomendacji. Ostrzega przed gwarancjami pierwszej pozycji, „specjalnymi relacjami z Google”, tajemniczymi metodami i bezrefleksyjnym traktowaniem raportów z narzędzi firm trzecich jako prawdy objawionej. To ciekawy kontrast wobec rynku, na którym „darmowy audyt” bywa po prostu gotowym skryptem sprzedażowym.

„Kto panu to robił?” — najtańszy trik sprzedażowy w branży

Najłatwiejszy klient to klient, który już zapłacił komuś innemu i zaczyna się zastanawiać, czy został oszukany. Dlatego część handlowców nie zaczyna od pokazania własnych kompetencji. Zaczyna od rozbiórki reputacji poprzednika.

SCENARIUSZ SPRZEDAŻOWY

1. Znajdź stronę działającej firmy.
2. Odpal automatyczny crawler.
3. Wybierz 5-10 alertów.
4. Nie rozdzielaj błędów krytycznych od kosmetycznych.
5. Nie pytaj o historię wdrożenia.
6. Pokaż klientowi czerwone elementy.
7. Powiedz: "poprzednia firma tego nie zrobiła".
8. Zaoferuj abonament naprawczy.
9. W kolejnych miesiącach raportuj liczbę wykonanych czynności.
10. Nie pokazuj, czy czynności przełożyły się na biznes.

Problem nie polega na tym, że nowy wykonawca nie może znaleźć błędów. Powinien. Jeżeli canonical jest zły, robots blokuje kluczową sekcję, przekierowania tworzą pętlę, dane produktowe się rozjeżdżają albo Google wybrało inne canonicale niż właściciel witryny — trzeba to nazwać. Różnica tkwi w jakości dowodu.

Diagnoza techniczna

URL:
https://example.com/sklep/kawa/

PROBLEM:
Canonical wskazuje inny adres niż URL używany w sitemapie i linkowaniu.

DOWÓD:
<link rel="canonical" href="https://example.com/product?id=123">

SITEMAP:
https://example.com/sklep/kawa/

INTERNAL LINK:
<a href="/sklep/kawa/">Kawa</a>

RYZYKO:
Niespójne sygnały kanonizacji; Google może wybrać inną reprezentację.

NAPRAWA:
Ujednolicić canonical, sitemap, linki wewnętrzne i URL-y danych strukturalnych.

TEST:
curl + źródło HTML + Search Console URL Inspection.

Diagnoza handlowa

SEO SCORE: 63/100

!!! 18 BŁĘDÓW !!!
!!! 42 OSTRZEŻENIA !!!

Wniosek:
"Strona wymaga pilnego pozycjonowania".

Drugi raport może być użyteczny jako lista potencjalnych punktów kontrolnych. Nie jest jeszcze analizą przyczynową. Google samo przypomina, że narzędzia SEO firm trzecich nie mają dostępu do wewnętrznych danych rankingowych Google i nie są przez Google „zatwierdzane”.

Strona wygląda zajebiście. I co z tego, jeżeli pod spodem jest burdel?

Najczęstszy błąd właściciela firmy polega na utożsamieniu strony internetowej z tym, co widzi w przeglądarce. Frontend jest ważny. UX jest ważny. Mobile jest ważny. Estetyka jest ważna. Ale to nadal tylko jedna warstwa.

STRONA INTERNETOWA
│
├── UI / UX
│   ├── layout
│   ├── mobile
│   ├── formularze
│   └── nawigacja
│
├── HTML
│   ├── semantyka
│   ├── H1-H6
│   ├── linki
│   ├── obrazy
│   └── treść renderowana
│
├── HTTP
│   ├── 200
│   ├── 301
│   ├── 404 / 410
│   ├── cache
│   └── headers
│
├── SEO techniczne
│   ├── canonical
│   ├── robots
│   ├── sitemap
│   ├── indeksacja
│   └── architektura URL
│
├── Dane strukturalne
│   ├── Organization
│   ├── WebSite
│   ├── WebPage
│   ├── Article / Product / Event
│   ├── Person
│   └── relacje @id
│
├── Discovery
│   ├── sitemap.xml
│   ├── feeds
│   ├── Merchant Center
│   └── News / Discover, jeśli dotyczy
│
├── Analityka
│   ├── Search Console
│   ├── GA4
│   ├── GTM
│   └── cele / konwersje
│
├── Integracje
│   ├── płatności
│   ├── CRM / ERP
│   ├── faktury
│   ├── dostawy
│   └── API
│
└── Utrzymanie
    ├── backup
    ├── aktualizacje
    ├── bezpieczeństwo
    ├── licencje
    └── monitoring

Możesz mieć projekt graficzny premium i jednocześnie:

• strony kategorii generujące tysiące niepotrzebnych URL-i,
• canonical prowadzący w złe miejsce,
• produkt z inną ceną w HTML, inną w Schema i jeszcze inną w feedzie,
• menu wykonane jako JavaScript bez sensownego <a href>,
• duplikaty Organization generowane przez trzy pluginy,
• brak właściciela Search Console, bo wszystko jest na prywatnym Gmailu wykonawcy,
• formularz kontaktowy zależny od licencji agencji,
• premium page builder bez aktywnej licencji po zakończeniu umowy.

I odwrotnie: wizualnie skromna strona może mieć bardzo solidną architekturę informacji, szybki backend, poprawne indeksowanie, czysty graf danych i dobrze zaplanowane linkowanie. Ocena „ładne/brzydkie” nie jest audytem SEO.

Audyt SEO powinien przypominać code review, a nie horoskop z czerwonymi ikonkami

Programista nie zaczyna od wyniku „SEO Health 71”. Zaczyna od wejścia i wyjścia systemu. Najpierw odpowiedź serwera, potem finalny URL, HTML, nagłówki, zasoby, canonical, robots, sitemap, renderowanie i Search Console.

HTTP

curl -I https://example.com/

HTTP/2 200
content-type: text/html; charset=UTF-8
cache-control: max-age=0
server: nginx

Albo:

curl -IL http://example.com

http://example.com
        ↓ 301
https://www.example.com
        ↓ 302
https://example.com
        ↓ 301
https://example.com/
        ↓ 200

Tu jest już konkret: trzy zbędne przejścia. Można wskazać koszt i sposób naprawy.

Canonical

curl -sL https://example.com/oferta/ \
| grep -i 'rel="canonical"'

Sprawdzamy nie tylko, czy canonical istnieje. Sprawdzamy, czy zgadza się z:

• finalnym URL-em po przekierowaniach,
• sitemapą,
• linkowaniem wewnętrznym,
• og:url,
• url i mainEntityOfPage w JSON-LD,
• wersją wybraną przez Google w Search Console.

Robots

curl -sL https://example.com/ \
| grep -i 'name="robots"'

Piękna strona, świetne teksty, mocne linki i:

<meta name="robots" content="noindex,follow">

To zdarza się po migracjach, stagingach i źle skonfigurowanych pluginach. Żaden „content plan na 30 artykułów” tego nie naprawi.

Robots.txt

curl https://example.com/robots.txt

Można zobaczyć:

User-agent: *
Disallow: /

i nagle „problem z brakiem widoczności” ma bardzo konkretną przyczynę.

Minimalny skrypt kontrolny

import requests
from bs4 import BeautifulSoup

URL = "https://example.com/artykul/"

r = requests.get(URL, timeout=15, allow_redirects=True)
soup = BeautifulSoup(r.text, "html.parser")

print("HTTP:", r.status_code)
print("FINAL:", r.url)
print("TITLE:", soup.title.get_text(strip=True) if soup.title else "BRAK")

canonical = soup.find("link", rel="canonical")
print("CANONICAL:", canonical.get("href") if canonical else "BRAK")

robots = soup.find("meta", attrs={"name": "robots"})
print("ROBOTS:", robots.get("content") if robots else "BRAK")

print("H1:", len(soup.find_all("h1")))
print("JSON-LD:", len(soup.find_all("script", type="application/ld+json")))

To jest prosty skrypt, ale daje właścicielowi serwisu więcej konkretu niż wiele „audytów premium”.

Płatne wtyczki, o których klient dowiaduje się dopiero, gdy coś przestaje działać

Jedna z bardziej perfidnych patologii nie wygląda jak SEO. Wygląda jak „profesjonalne wdrożenie WordPressa”. Klient dostaje gotową stronę i fakturę za projekt. Nie dostaje natomiast listy zależności, licencji, właścicieli kont ani informacji, że połowa funkcji działa dlatego, że wykonawca podpiął własne konto agencyjne.

Po roku współpraca się kończy. Wtedy okazuje się, że:

• page builder jest aktywowany licencją agencji,
• wtyczka formularzy premium przestaje dostawać aktualizacje,
• moduł SEO premium jest przypisany do konta wykonawcy,
• system backupów działa przez konto agencji,
• cache/CDN korzysta z zewnętrznego konta, do którego klient nie ma dostępu,
• obrazy są optymalizowane usługą z miesięcznym limitem wykonawcy,
• szablon premium został kupiony raz i użyty na wielu stronach mimo ograniczeń licencji,
• „autorski system” jest zestawem pięciu komercyjnych pluginów spiętych konfiguracją.

Minimalna lista zależności powinna wyglądać jak normalna dokumentacja projektu

DEPENDENCIES.md

WordPress: 6.x
PHP: 8.3
Web server: nginx

PLUGINS:
- WooCommerce
  owner: client
  license: open source
  critical: yes

- Elementor Pro
  owner: client
  license_account: klient@example.com
  renewal: 2027-01-10
  critical: yes

- WP Rocket
  owner: client
  renewal: 2027-02-03
  critical: no

- Custom SEO Schema Plugin
  owner: client
  repository: git@example.com/client/seo-schema.git
  critical: yes

EXTERNAL SERVICES:
- Cloudflare
  owner: client
- Google Search Console
  owner: client
- GA4
  owner: client
- SMTP
  owner: client
- Backup storage
  owner: client

To nie jest fanaberia. WordPress jest ekosystemem zależności. Raport Patchstack „State of WordPress Security in 2026” podaje, że w 2025 roku wykryto 11 334 nowe podatności w ekosystemie WordPressa, z czego 91% dotyczyło wtyczek. 17% nowych podatności miało wysoki poziom ryzyka masowego wykorzystania. To nie znaczy, że „wtyczki są złe”. Znaczy, że właściciel serwisu powinien wiedzieć, z czego jego system się składa i kto odpowiada za aktualizacje.

Premium nie oznacza złe. Ukryte premium oznacza problem organizacyjny

Komercyjna wtyczka może być świetnym wyborem. Czasem zakup sprawdzonego komponentu jest rozsądniejszy niż pisanie wszystkiego od zera. Patologia zaczyna się wtedy, kiedy cena usługi ukrywa model zależności, a klient dowiaduje się o nim dopiero po zmianie wykonawcy.

Abonament „8 artykułów miesięcznie”: produkcja kilogramów tekstu jako usługa SEO

Drugi klasyczny produkt to abonament contentowy. Nie zaczynamy od pytań, które użytkownicy zadają, nie analizujemy danych Search Console, nie projektujemy klastrów, nie ustalamy encji i relacji. Najpierw ustalamy liczbę sztuk.

PAKIET BASIC
4 artykuły / miesiąc

PAKIET PRO
8 artykułów / miesiąc

PAKIET ULTRA SEO MAX
16 artykułów / miesiąc
+ 100 linków
+ raport

Dlaczego cztery? Dlaczego osiem? Dlaczego szesnaście? Bo łatwo to policzyć na fakturze.

To nie znaczy, że regularna publikacja jest zła. Problemem jest odwrócenie procesu. Najpierw powinien istnieć problem informacyjny i strategia. Dopiero z niej wynika liczba materiałów.

Fabryka tekstu wygląda zwykle tak

keyword list
    ↓
AI / copywriter
    ↓
1500 słów
    ↓
"fraza główna" 8 razy
    ↓
stock photo
    ↓
Yoast green
    ↓
publish
    ↓
next article

Po roku klient ma 96 wpisów. Pytanie brzmi: ile z nich odpowiada na realne zapytania, ile ma ruch, ile prowadzi do usług lub produktów, ile pozyskało linki, ile zostało zaktualizowanych, ile kanibalizuje inne strony i ile w ogóle znajduje się w indeksie?

Google nazywa problem po imieniu

W aktualnych zasadach spamu Google „scaled content abuse” obejmuje tworzenie dużej liczby stron przede wszystkim w celu manipulacji rankingami, a nie pomocy użytkownikowi. Google podaje wprost przykłady: masowe generowanie stron z użyciem AI bez dodanej wartości, składanie treści z innych witryn, tworzenie wielu stron o niewielkiej wartości i produkowanie stron zawierających frazy, ale mało sensu dla czytelnika.

To nie jest zakaz używania AI. To jest zakaz robienia z AI taśmy produkcyjnej do zalewania indeksu gównem.

Dobry proces contentowy jest odwrotny

Search Console / dane klientów / support / sprzedaż
                 ↓
            realne pytanie
                 ↓
              intencja
                 ↓
           główna encja
                 ↓
      istniejące materiały serwisu
                 ↓
     decyzja: nowa strona czy update?
                 ↓
              źródła
                 ↓
      własna wiedza / dane / przykład
                 ↓
              artykuł
                 ↓
  linkowanie + Schema + meta + obraz
                 ↓
             publikacja
                 ↓
       pomiar zapytań i konwersji
                 ↓
             aktualizacja

Tekst nie powinien istnieć tylko dlatego, że jest w kalendarzu

Dobry materiał może mieć 600 słów, jeśli odpowiedź jest kompletna. Może mieć 6000, jeśli temat tego wymaga. Badanie Backlinko na 11,8 mln wyników wykazało, że bardziej kompleksowe treści mierzone przez Content Grade korelowały z wyższymi pozycjami, ale autorzy wyraźnie podkreślili, że jest to korelacja, a nie dowód przyczynowości. To nie daje licencji na pisanie „dłużej = lepiej”. Daje argument za pełnym pokryciem problemu.

Grupy Facebookowe „zlecę SEO” — cyfrowy targ, na którym wszyscy są najlepsi, dopóki nie trzeba pokazać architektury

Mechanika publicznych grup zleceniowych jest brutalnie prosta. Ktoś pisze:

Szukam osoby do zrobienia strony i SEO.
Branża: usługi.
Proszę o cenę.

Po chwili pojawia się:

priv
priv
zapraszam
799 zł
napisałem wiadomość
SEO gratis
strona 3 dni
mogę zrobić za 500
portfolio na priv
mamy 15 lat doświadczenia

Największy problem polega na tym, że nikt jeszcze nie zdefiniował produktu. Jedna osoba wycenia gotowy motyw. Druga indywidualny frontend. Trzecia WordPress + SEO. Czwarta sklep z płatnościami. Piąta stronę z poprawnym Schema, migracją, przekierowaniami, Search Console, analityką i testami. Wszystko zostaje sprowadzone do jednej kolumny: cena.

Nie da się sensownie porównać ofert bez kontraktu technicznego

Jeżeli zakresu nie ma, cena mówi prawie nic. Właśnie dlatego na grupach wygrywa często nie najlepsze rozwiązanie, tylko osoba, która najszybciej wyśle „priv” i obieca najwięcej w jednym zdaniu.

Druga patologia: podbieranie klienta przez publiczną egzekucję poprzednika

Klient wrzuca pytanie o drobny problem. Zamiast odpowiedzi dostaje:

"Ta strona jest cała do przebudowy."
"Kto to robił?"
"SEO leży."
"To jest tragedia."
"Napisz priv, zrobię ci audyt."

Bez dostępu do historii zmian, Search Console, logów, briefu, ograniczeń budżetowych i celu projektu. To nie jest code review. To performance sprzedażowy wykonywany publicznie.

Farmy linków: 500 backlinków w Excelu i zero odpowiedzi na pytanie „po co?”

Linki nadal są ważnym elementem ekosystemu wyszukiwania. To właśnie dlatego wokół link buildingu wyrosła potężna fabryka półproduktów: katalogi, PBN-y, automatyczne profile, sponsorowane artykuły na portalach bez odbiorców, wymiany „A do B, B do C”, domeny po przejęciu i pakiety sprzedawane na kilogram.

Klasyczny raport

LINK BUILDING — SIERPIEŃ

Pozyskano: 173 linki

✓ 52 katalogi
✓ 31 profile
✓ 18 komentarzy
✓ 42 publikacje zapleczowe
✓ 30 bookmarków

Wzrost liczby backlinków: +173
STATUS: SUKCES

To raport aktywności. Nie raport jakości.

Minimalny raport powinien pozwalać odtworzyć każdy link

source_url,target_url,anchor,rel,type,date,cost,status
https://portal-a.pl/artykul,https://firma.pl/usluga/,audyt techniczny,,editorial,2026-09-01,0,live
https://portal-b.pl/material,https://firma.pl/,Firma X,sponsored,sponsored,2026-09-02,800,live

Do tego sensownie jest przechowywać:

• domenę źródłową,
• typ publikacji,
• temat strony źródłowej,
• URL docelowy,
• anchor,
• rel,
• koszt,
• datę,
• status po 30/90/180 dniach,
• informację, czy publikacja była sponsorowana.

Google nie zostawia tu dużego pola do interpretacji

W aktualnych Spam Policies Google definiuje link spam jako tworzenie linków do lub z witryny przede wszystkim w celu manipulacji rankingami. Jako przykłady wymienia m.in. kupowanie i sprzedawanie linków rankingowych, nadmierne wymiany, automatyczne programy generujące linki, niskiej jakości katalogi i bookmarki, szeroko rozprowadzane linki w stopkach, zoptymalizowane anchory w płatnych artykułach i spam w komentarzach. Płatna reklama sama w sobie nie jest problemem, jeśli link zostanie odpowiednio zakwalifikowany, np. rel="sponsored" lub nofollow.

Katalog firmy vs katalog istniejący dlatego, że sprzedaje link

Sam fakt, że coś jest katalogiem, nie czyni tego śmieciem. Lokalny katalog przedsiębiorców może pomagać ludziom znaleźć firmę, mieć moderowane profile, adresy, mapy i realny ruch.

Inny model to:

seo-katalog-98273.example

Kategorie:
- pożyczki
- implanty
- pompy ciepła
- kasyno
- rolety
- weterynarz
- kryptowaluty
- pogrzeby
- moda
- software

Każdy wpis:
- 800 słów
- zdjęcie stockowe
- 2 linki komercyjne
- autor: Redakcja
- zero realnego odbiorcy

Dobry test mentalny:

PBN: „mamy własne zaplecze”

Brzmi ekskluzywnie. Problem zaczyna się, gdy klient nie zna domen, nie zna kosztu, nie wie, czy linki zostaną po zakończeniu umowy i nie ma dostępu do żadnego raportu poza liczbą „publikacji”.

KLIENT → płaci 3000 zł / miesiąc
              ↓
         "nasze zaplecze"
              ↓
              ???
              ↓
         backlinki

Jeżeli metoda jest tajna do tego stopnia, że klient nie może zobaczyć, gdzie opublikowano jego markę, problemem przestaje być SEO. Problemem staje się kontrola nad własną reputacją.

Co mówią dane o linkach

Badanie Ahrefs opublikowane w 2025 r. przeanalizowało milion popularnych zapytań w USA i policzyło korelacje Spearmana między pozycjami a różnymi metrykami. Liczba domen odsyłających miała korelację około 0,255, liczba backlinków około 0,248. Autorzy wyraźnie zaznaczają: korelacja jest słaba i nie oznacza przyczynowości. Dla zapytań lokalnych korelacja linków/referring domains była wyższa — około 0,33. Wniosek jest bardziej subtelny niż „kup linki”: linki są jednym z sygnałów i ich znaczenie zależy od kontekstu.

Badanie Backlinko na 11,8 mln wyników również wykazało, że strony z większą liczbą backlinków i domen odsyłających częściej zajmują wyższe pozycje; wynik #1 miał średnio 3,8 raza więcej backlinków niż wyniki #2–#10. To nadal badanie korelacyjne. Nie dowodzi, że dokupienie 1000 katalogów przeniesie URL na pierwsze miejsce.

Toksyczne linki, doorway pages, „parasite SEO”, stare domeny i inne patologie sprzedawane jako spryt

Rynek SEO lubi tworzyć nowe nazwy dla starych pomysłów. Czasem jest to realna specjalizacja. Czasem wystarczy zmienić nazwę techniki manipulacyjnej, żeby po kwartale wróciła jako „growth hack”.

„Ma pan 347 toksycznych linków. Trzeba pilnie zrobić disavow”

To jedna z najwygodniejszych usług strachu, bo klient nie ma jak ocenić zagrożenia. Narzędzie firm trzecich pokazuje Toxicity 71%, więc raport wygląda jak diagnoza medyczna.

BACKLINK AUDIT

Toxic links: 347
Potentially toxic: 912
Healthy: 144

RECOMMENDATION:
monthly toxic link cleanup
+ disavow update
+ monitoring package

Tymczasem oficjalna dokumentacja Google dotycząca Disavow mówi wprost: to zaawansowane narzędzie, którego większość witryn nie potrzebuje. Google zaleca jego użycie przede wszystkim wtedy, gdy istnieje znaczna liczba spamowych/sztucznych linków i spowodowały one manual action albo istnieje realne ryzyko takiej akcji — np. dlatego, że właściciel lub zatrudnione SEO wcześniej budowało płatne schematy linków. Błędne użycie Disavow może zaszkodzić.

Doorway pages: 400 miast, ten sam tekst, zmieniona nazwa miejscowości

/seo-krakow/
/seo-katowice/
/seo-chrzanow/
/seo-olkusz/
/seo-wadowice/
/seo-zator/
...

Treść:
"Oferujemy profesjonalne SEO w {CITY}."
"Nasza agencja SEO w {CITY}..."
"Najlepsze pozycjonowanie {CITY}..."

Jeżeli firma rzeczywiście działa lokalnie, posiada oddziały, ludzi, realizacje, dane adresowe i unikalną ofertę regionalną, osobne strony lokalizacji mogą mieć sens. Patologia zaczyna się wtedy, gdy tworzy się setki prawie identycznych dokumentów wyłącznie po to, aby przechwycić warianty zapytań i wszystkie kierują użytkownika do tej samej usługi.

Google klasyfikuje „doorway abuse” jako tworzenie stron lub witryn pod podobne zapytania, które prowadzą użytkownika do pośrednich, mało użytecznych miejsc zamiast klarownej hierarchii. Wśród przykładów wymienia masowe strony regionalne/city pages prowadzące do jednego celu.

Expired domain abuse: kupmy starą domenę i załóżmy na niej kompletnie inny biznes

Stara domena z historią i linkami może mieć wartość, jeśli przejmujesz realny projekt, markę albo kontynuujesz temat w logiczny sposób. Problemem jest kupowanie wygasłej domeny wyłącznie po to, żeby wykorzystać jej dawną reputację do rankowania treści niezwiązanych z historią serwisu.

Google w Spam Policies wymienia expired domain abuse wprost — np. wykorzystanie dawnej strony instytucji do publikowania komercyjnych treści całkowicie niezwiązanych z jej poprzednim przeznaczeniem.

Site reputation abuse / „parasite SEO”

Model jest kuszący:

silna domena medialna
      +
sekcja zewnętrznego partnera
      +
komercyjne artykuły
      +
rankingi typu "najlepsze X"
      ↓
próba wykorzystania reputacji hosta

Google określa site reputation abuse jako publikowanie treści zewnętrznych na silnej domenie głównie po to, aby wykorzystać istniejące sygnały rankingowe hosta. W sierpniu 2026 r. Google dodatkowo zaktualizowało sposób egzekwowania tej polityki w Europejskim Obszarze Gospodarczym, ale sama zasada nadal pozostaje częścią polityk antyspamowych.

„Artykuł sponsorowany” udający niezależny ranking

Jeszcze ciekawszy model:

NAJLEPSZE FIRMY SEO 2026

1. Firma, która zapłaciła za publikację
2. Firma partnerska
3. Firma partnerska
4. ktoś prawdziwy dla wiarygodności

Autor: Redakcja
Disclosure: brak

To przestaje być tylko SEO. Wchodzi w obszar transparentności reklamowej, reputacji wydawcy i zaufania użytkownika. Jeżeli ranking jest produktem handlowym, powinien być opisany jak produkt handlowy.

Automatyczny „audyt konkurencji” oparty na metrykach firm trzecich

Typowy slajd:

TY: DR 18
KONKURENCJA: DR 44

TY: 320 BACKLINKS
KONKURENCJA: 12 000 BACKLINKS

WNIOSEK:
musimy zwiększyć budżet link buildingu

To może być punkt startowy, ale nie odpowiedź. Konkurent może mieć:

• 10 lat historii marki,
• ogólnopolskie PR-y,
• linki redakcyjne wynikające z realnych wydarzeń,
• produkty cytowane przez media,
• dużo większy brand search,
• inną architekturę serwisu i inny profil zapytań.

Nie da się skopiować 10 lat reputacji przez zamówienie „11 680 backlinków”.

Sprzedaż „AI SEO / GEO / AEO” jako nowej tajnej sztuki

Zmieniają się interfejsy wyszukiwania i sposób konsumowania informacji, więc optymalizacja pod systemy generatywne jest realnym obszarem rozwoju. Patologia zaczyna się, gdy ktoś sprzedaje tajne „promptowanie Google” albo obiecuje gwarantowane cytowania w AI bez pokazania modelu danych, źródeł, crawlability, reputacji i jakości treści.

Nawet aktualny poradnik Google dla osób zatrudniających SEO sugeruje sprawdzanie, czy rady dotyczące „AEO/GEO” są zgodne z oficjalnymi wskazówkami Google dla generatywnych funkcji wyszukiwarki.

Raportowanie pozycji bez ruchu i bez konwersji

fraza A: 19 → 11
fraza B: 8 → 6
fraza C: 43 → 21
fraza D: 12 → 9

SUKCES +++++

Brakuje:

wyświetlenia?
kliknięcia?
CTR?
landing page?
brand / non-brand?
konwersje?
przychód?
telefon?
formularz?
wartość leadu?

Pozycja dla frazy, której nikt nie szuka albo która nie prowadzi do żadnej wartości biznesowej, jest świetnym KPI dla agencji i kiepskim KPI dla klienta.

Linkowanie wewnętrzne: jedna z najtańszych rzeczy, które potrafią realnie zmienić wynik

Paradoks branży polega na tym, że część firm potrafi miesiącami sprzedawać link building, nie porządkując najpierw własnego grafu linków klienta. Tymczasem linkowanie wewnętrzne jest w pełni pod kontrolą właściciela strony, pomaga użytkownikowi, pomaga crawlerowi i może zmieniać przepływ sygnałów między dokumentami.

Nie chodzi o „więcej linków”. Chodzi o lepszą architekturę

STRONA GŁÓWNA
    │
    ├── /seo/
    │     ├── /seo/canonical/
    │     ├── /seo/schema/
    │     ├── /seo/linkowanie-wewnetrzne/
    │     └── /seo/search-console/
    │
    ├── /strony-internetowe/
    │     ├── /wordpress/
    │     ├── /woocommerce/
    │     └── /wydajnosc/
    │
    └── /realizacje/
          ├── /realizacje/sklep-audio/
          └── /realizacje/portal/

Jeżeli artykuł o Schema.org nie prowadzi do strony usługi SEO, a strona usługi nie prowadzi do materiałów technicznych, serwis tworzy odseparowane wyspy. Użytkownik traci kontekst. Robot musi polegać na menu, sitemapie i przypadkowych odnośnikach.

Anchor powinien opisywać cel

Słabo:

<a href="/seo/">kliknij tutaj</a>
<a href="/seo/">więcej</a>
<a href="/seo/">sprawdź</a>

Lepiej:

<p>
  Przy migracji sklepu warto wcześniej przygotować
  <a href="/seo-techniczne/">audyt technicznego SEO</a>,
  który obejmuje canonical, przekierowania, sitemapę i indeksację.
</p>

Google w dokumentacji linków zaleca opisowy, zwięzły anchor i sensowny kontekst wokół odnośnika. Jednocześnie ostrzega przed nienaturalnym upychaniem słów kluczowych.

Kontrolowane testy są ciekawsze niż teorie

SearchPilot opisał test na serwisie Iceland Groceries, w którym dodano dodatkowe linkowanie między kategoriami poziomu 2 i 3. Wynik: około 25% wzrostu organicznego ruchu łącznie dla badanych grup, szacunkowo około 9200 dodatkowych sesji miesięcznie. SearchPilot podkreśla, że sukces wynikał prawdopodobnie z poprawy architektury informacji, a nie z mechanicznego „dodania dużej liczby linków”.

W innym teście na około 8000 stron lokalizacyjnych dodanie systematycznych linków do sześciu pobliskich regionów dało około 7% wzrostu ruchu organicznego na stronach, które otrzymały dodatkowe linki.

Schema.org: nie booster rankingu, tylko maszynowy model tej samej rzeczywistości

Jedna z najczęściej sprzedawanych bajek brzmi mniej więcej:

"Wdrożymy zaawansowane Schema.
Google lepiej pana zrozumie.
Pozycje pójdą do góry."

Pierwsze zdanie może być prawdziwe. Drugie jest zgodne z celem danych strukturalnych. Trzecie nie wynika automatycznie z dwóch pierwszych.

Badanie Backlinko na 11,8 mln wyników nie znalazło korelacji między samą obecnością Schema markup a wyższą pozycją. SearchPilot w teście wdrożenia Article Schema również nie wykrył jednoznacznego wzrostu ruchu. Z drugiej strony niektóre wdrożenia structured data prowadzące do określonych rich results potrafiły w kontrolowanych testach zmieniać CTR i ruch — np. test samego review markup na stronach produktowych dał w konkretnym serwisie około 20% wzrostu ruchu, podczas gdy wariant z ceną i oceną był wcześniej nierozstrzygający. Kontekst ma znaczenie.

Najważniejsza wartość Schema jest architektoniczna

Schema.org daje słownik typów, właściwości i relacji. W dobrze zaprojektowanym serwisie JSON-LD nie jest osobnym światem. Jest reprezentacją danych, które już istnieją w systemie.

DATABASE / CMS
       │
       ├── author_id
       ├── title
       ├── canonical_url
       ├── image_id
       ├── datePublished
       ├── dateModified
       ├── organization_id
       └── entity relationships
       │
       ▼
   NORMALIZACJA
       │
       ├─────────────┬─────────────┬─────────────┐
       ▼             ▼             ▼             ▼
      HTML         JSON-LD        REST          FEED
       │             │             │             │
       └─────────────┴─────────────┴─────────────┘
                     │
                     ▼
              TA SAMA INFORMACJA

Jeżeli artykuł ma autora „Kamil Mystek”, ten sam autor powinien występować konsekwentnie w HTML, profilu autora, Article.author, API i wszędzie tam, gdzie system publikuje tę informację.

Jedna encja, jeden stabilny identyfikator

{
  "@type": "Person",
  "@id": "https://example.com/autor/kamil/#person",
  "name": "Kamil Mystek",
  "url": "https://example.com/autor/kamil/"
}

Artykuł nie musi ponownie definiować osoby:

{
  "@type": "Article",
  "@id": "https://example.com/artykul/#article",
  "author": {
    "@id": "https://example.com/autor/kamil/#person"
  }
}

Pięćdziesiąt artykułów może wskazywać tę samą encję Person. Ta sama zasada dotyczy Organization, produktu, marki, wydarzenia i innych obiektów.

Schema jako detektor niespójności

HTML:
Cena: 4 999 zł

JSON-LD:
"price": "4599"

API:
"price": 5199

FEED:
4899 PLN

To nie jest „błąd Schema”. To dowód, że system nie ma jednego źródła prawdy o cenie. Dobre wdrożenie structured data bardzo szybko ujawnia takie rozjazdy.

Patologia WordPressowa: pięciu właścicieli tej samej encji

MOTYW
└── Organization #1

PLUGIN SEO
├── Organization #2
├── WebSite
└── Article #1

PLUGIN SCHEMA
├── Organization #3
└── Article #2

WOOCOMMERCE
├── Product #1
└── Offer #1

CUSTOM CODE
└── Product #2

Każdy ma inne @id, logo, nazwę, URL albo cenę. Klient słyszy: „mamy bardzo rozbudowane Schema”. Technicznie ma kilku niezależnych producentów tych samych danych.

Lepszy model

EntityRepository
│
├── Organization
├── Person
├── Article
├── Product
├── Offer
├── ImageObject
└── Event
     │
     ▼
 SchemaBuilder
     │
     ▼
   @graph

$author = EntityRepository::author($post->author_id);
$publisher = EntityRepository::organization();

$article = [
    '@type' => 'Article',
    '@id'   => canonical_url($post) . '#article',
    'headline' => $post->title,
    'author' => ['@id' => $author->schema_id],
    'publisher' => ['@id' => $publisher->schema_id],
    'datePublished' => $post->published_at->format(DATE_ATOM),
    'dateModified' => $post->modified_at->format(DATE_ATOM),
];

Google wymaga, aby structured data było zgodne z treścią widoczną dla użytkownika i nie wprowadzało w błąd. To dodatkowo wzmacnia zasadę spójności: JSON-LD nie może opisywać wymyślonej ceny, opinii, autora ani FAQ, którego na stronie nie ma.

Canonical, robots, sitemap, statusy HTTP i indeksacja — SEO, którego nie widać na makiecie

Hiena lubi rzeczy, które można sprzedać jako tajemniczą wiedzę. Tymczasem ogromna część technicznego SEO jest bardzo konkretna i możliwa do sprawdzenia.

Canonical

<link rel="canonical" href="https://example.com/produkt/kawa/">

Google traktuje canonical jako silny sygnał, ale może wybrać inną wersję. Dlatego kontrolujemy cały zestaw sygnałów:

REQUEST URL
    ↓
FINAL URL
    ↓
CANONICAL
    ↓
SITEMAP
    ↓
INTERNAL LINKS
    ↓
OPEN GRAPH URL
    ↓
SCHEMA URL / mainEntityOfPage
    ↓
GOOGLE-SELECTED CANONICAL

Sitemap

Sitemap nie jest kontenerem „wszystkich adresów, które umie wyprodukować CMS”. Powinna przekazywać URL-e, które właściciel rzeczywiście chce utrzymywać jako istotne strony serwisu.

<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.com/</loc>
    <lastmod>2026-09-07</lastmod>
  </url>
  <url>
    <loc>https://example.com/seo-techniczne/</loc>
    <lastmod>2026-09-06</lastmod>
  </url>
</urlset>

Śmieciowy wariant:

/?replytocom=123
/search/test
/tag/test-123
/attachment/image-443
/?filter_color=red
/?orderby=price
/author/admin/page/48

Statusy HTTP

Indeksacja to stan, nie checkbox

Właściwe pytania brzmią:

• które klasy URL-i powinny być indeksowane,
• które nie powinny,
• które Google odkrywa, ale nie indeksuje,
• które canonicale Google wybiera inaczej niż serwis,
• które strony są sierotami bez linków wewnętrznych,
• które generują duplikaty,
• które mają ruch i konwersje.

To jest praca z Search Console, logami, crawlerem i bazą danych. Nie da się jej uczciwie sprowadzić do „wtyczka pokazuje zielone”.

Title, description, H1 i semantyczny HTML — podstawy, które nadal warto robić dobrze

Fakt, że SEO jest większe niż title i description, nie oznacza, że te elementy są nieważne. Właśnie tutaj widać różnicę między optymalizacją a szablonowym wciskaniem fraz.

Title nie jest workiem na słowa kluczowe

<title>
  Techniczne SEO sklepów internetowych | Example
</title>

zamiast:

<title>
SEO sklepów, SEO sklep, pozycjonowanie sklepu,
pozycjonowanie sklepów tanio, najlepsze SEO sklepów
</title>

SearchPilot pokazuje, że zmiany title potrafią dawać wyniki pozytywne i negatywne zależnie od kontekstu. W jednym zestawieniu testów poprawa tytułów przyniosła około 8,5% i 10% wzrostu ruchu w różnych eksperymentach. W innym teście dodanie ceny do tytułów dało około 15% spadku. To bardzo dobry argument przeciwko „uniwersalnej formule title”.

H1 jest elementem dokumentu, nie dekoracją CSS

Źle:

<div class="hero-title">
  Tworzenie stron internetowych
</div>

Semantycznie:

<main>
  <article>
    <header>
      <h1>Tworzenie stron internetowych dla firm</h1>
    </header>

    <section>
      <h2>Projekt i UX</h2>
    </section>

    <section>
      <h2>Techniczne SEO</h2>
      <h3>Dane strukturalne Schema.org</h3>
    </section>
  </article>
</main>

HTML structure też potrafi mieć znaczenie

SearchPilot opisał kontrolowany test, w którym bez zmiany samej treści przebudowano kolejność HTML tak, aby ważna zawartość pojawiała się wcześniej niż sidebar. W badanej grupie odnotowano około 16% wzrostu organicznego ruchu. Autorzy wiązali wynik z lepszym dopasowaniem do użytkownika i sposobem interpretacji strony. To nie oznacza, że „przesuń div wyżej = +16%”. Pokazuje, że techniczna struktura dokumentu może mieć znaczenie i warto testować zmiany na własnym serwisie.

Kto jest właścicielem strony? To pytanie potrafi zaboleć bardziej niż cały audyt SEO

Można mieć perfekcyjne meta tagi i jednocześnie nie mieć realnej kontroli nad własnym serwisem. To jedna z najbardziej niedocenianych patologii. Właściciel firmy płaci za stronę, ale domena jest na konto wykonawcy, hosting na konto wykonawcy, Search Console na prywatnym Gmailu wykonawcy, Cloudflare na wykonawcy, licencje premium na wykonawcy, a repozytorium kodu nie istnieje albo jest prywatne.

Wtedy zmiana dostawcy zaczyna przypominać odzyskiwanie zakładnika.

Minimalny model własności

CLIENT ORGANIZATION
│
├── domain registrar
├── DNS / Cloudflare
├── hosting / VPS
├── WordPress admin
├── database access
├── SFTP / SSH
├── repository
├── Google Search Console
├── GA4
├── GTM
├── Google Business Profile
├── Merchant Center
├── SMTP
├── backup storage
└── premium licenses

AGENCY
└── delegated access
    ├── admin / developer
    ├── analytics
    └── support

Model powinien być prosty: klient posiada, wykonawca dostaje uprawnienia. Nie odwrotnie.

Co klient powinien dostać przy odbiorze

• listę kont i właścicieli,
• listę aktywnych licencji,
• listę zewnętrznych usług,
• repozytorium lub paczkę źródłową kodu custom,
• backup plików i bazy,
• instrukcję odtworzenia,
• opis cronów i automatyzacji,
• opis integracji API i kluczy,
• mapę DNS,
• mapę przekierowań, jeśli była migracja,
• listę miejsc, w których skonfigurowano SEO,
• informację, co wymaga abonamentu.

Hiena lubi uzależnienie, bo ono zwiększa retencję

Najłatwiej zatrzymać klienta nie dlatego, że jest zadowolony, tylko dlatego, że boi się odejść. „Jak pan zrezygnuje, nie gwarantujemy działania strony”, „licencje są nasze”, „nie możemy przekazać dostępu”, „to nasza technologia”, „bez abonamentu przestaje działać SEO”.

Jeżeli funkcja rzeczywiście wymaga usługi abonamentowej, trzeba to jasno powiedzieć przed zakupem. Jeżeli natomiast zwykły eksport strony staje się niemożliwy, bo wszystko zostało świadomie przywiązane do wykonawcy, to nie jest przewaga technologiczna. To vendor lock-in.

Co naprawdę działa w SEO? Badania korelacyjne, testy kontrolowane i rzeczy, których nie wolno mieszać

Branża uwielbia zdania typu „to działa”, „to jest czynnik rankingowy” i „Google lubi”. Problem: pod tymi zdaniami mogą kryć się zupełnie różne poziomy dowodu.

1. Backlinki i domeny odsyłające: korelują, ale „kup 1000 linków” z tego nie wynika

Ahrefs przeanalizował milion popularnych zapytań i policzył korelacje Spearmana między pozycją w top 20 a metrykami linkowymi. Liczba domen odsyłających miała około 0,255, backlinków około 0,248, followed referring domains około 0,250. Autor wprost ostrzega: są to korelacje słabe i nie można ich interpretować jako dowodu przyczynowego.

Co ciekawe, dla zapytań lokalnych korelacja linków/referring domains wyniosła około 0,33. Ahrefs sugeruje, że przy podobnych ofertach lokalnych linki mogą być jednym z elementów różnicujących popularność firm.

Wniosek praktyczny: linki są częścią większego systemu, nie abonamentowym licznikiem sztuk.

2. Badanie 11,8 mln wyników Backlinko: autorytet, linki i kompleksowość treści współwystępują z rankingami

Backlinko wraz z danymi Ahrefs przeanalizowało 11,8 mln wyników Google. Wśród głównych obserwacji: domeny z wyższym ogólnym autorytetem linkowym częściej zajmowały wyższe pozycje; wynik #1 miał średnio 3,8 raza więcej backlinków niż wyniki #2–#10; liczba domen odsyłających korelowała z rankingiem; bardziej kompleksowe treści mierzone przez Clearscope Content Grade wypadały lepiej.

Jednocześnie badanie nie wykazało korelacji między obecnością Schema markup a wyższym rankingiem. Autorzy konsekwentnie zaznaczają, że badanie korelacyjne nie pozwala ustalić przyczyny.

3. Internal linking: +25% w kontrolowanym teście

SearchPilot na serwisie Iceland Groceries dodał linki między kategoriami poziomu 2 i 3. Eksperyment był prowadzony z grupami kontrolnymi i wariantowymi. Wynik: około 25% wzrostu organicznego ruchu w połączonej grupie stron i szacunkowo około 9200 dodatkowych sesji miesięcznie.

To nie jest dowód, że każda strona dostanie +25%. To dowód, że w konkretnym serwisie poprawa architektury linkowania była zmianą o mierzalnym, dużym wpływie.

4. Internal links dla stron lokalizacyjnych: +7%

W innym teście SearchPilot na około 8000 stron regionalnych systematyczne dodanie linków do sześciu najbliższych regionów dało około 7% wzrostu organicznego ruchu na stronach otrzymujących linki. To dobrze pokazuje, dlaczego strony „sieroty” albo słabo wpięte w hierarchię mogą nie wykorzystywać swojego potencjału.

5. Przebudowa kolejności HTML: +16%

SearchPilot opisał eksperyment, w którym bez zmiany treści przeorganizowano HTML tak, aby ważna zawartość pojawiała się przed sidebarem. Efekt: około 16% wzrostu ruchu organicznego. To przykład, że architektura dokumentu i doświadczenie użytkownika mogą być istotne nawet wtedy, gdy tekst pozostaje identyczny.

6. Title tags: potrafią pomagać i potrafią zaszkodzić

W zestawieniu testów SearchPilot zmiany title dawały w różnych eksperymentach około 8,5% i 10% wzrostu ruchu. Jednocześnie test dodania ceny do tytułów na tysiącach stron produktowych przyniósł około 15% spadku. To świetny przykład, dlaczego „best practice” bez kontekstu może być niebezpieczna.

7. Structured data: nie jest jednolitym „czynnikiem +X%”

SearchPilot testował różne typy Schema. Dodanie Article Schema było nierozstrzygające. Dodanie dateModified również nie dało wykrywalnego wzrostu w opisanym teście. Z kolei w jednym eksperymencie sama prezentacja review markup na stronach produktowych przyniosła około 20% wzrostu ruchu, podczas gdy wcześniejszy wariant łączący cenę i oceny był nierozstrzygający. Structured data może zmieniać wygląd wyniku i CTR, ale nie istnieje uniwersalny „Schema = wzrost rankingu”.

8. FAQ Schema: historia pokazuje, dlaczego SEO trzeba testować i aktualizować

Starsze testy SearchPilot FAQ Schema często dawały pozytywne wyniki, czasem kilka–kilkanaście procent, ponieważ rich snippets zajmowały dużą przestrzeń w SERP. Później Google ograniczyło wyświetlanie FAQ rich results. To ważniejsza lekcja niż same liczby: taktyka zależna od wyglądu SERP może stracić wartość po zmianie produktu Google.

9. WordPress: zależności to również bezpieczeństwo

Patchstack w raporcie „State of WordPress Security in 2026” podał, że w 2025 roku wykryto 11 334 nowe podatności w ekosystemie WordPress. 91% dotyczyło pluginów, 9% motywów, a jedynie sześć zgłoszeń dotyczyło core. 17% nowych podatności sklasyfikowano jako wysokiego ryzyka masowego wykorzystania. Dla klienta praktyczny wniosek jest prosty: lista pluginów, właściciel licencji i procedura aktualizacji są częścią jakości technicznej strony.

Co zatem „najlepiej działa”?

Nie ma jednego przycisku. Z dostępnych danych i dokumentacji powtarzają się jednak bardzo rozsądne fundamenty:

Checklista: jak odebrać stronę i SEO tak, żeby hiena nie sprzedała ci dymu

Poniższa lista nie ma zastąpić audytu. Ma pozwolić właścicielowi firmy zadać pytania, które bardzo szybko pokazują poziom przejrzystości wykonawcy.

Własność i dostęp

1. Czy domena jest na koncie klienta?
2. Czy klient kontroluje DNS i Cloudflare?
3. Czy hosting/VPS jest na koncie klienta?
4. Czy klient ma pełnego administratora WordPressa?
5. Czy klient ma SFTP/SSH, jeśli architektura tego wymaga?
6. Czy istnieje kopia bazy i plików?
7. Czy backup został kiedykolwiek odtworzony testowo?
8. Czy klient jest właścicielem Search Console?
9. Czy klient jest właścicielem GA4 i GTM?
10. Czy Google Business Profile i Merchant Center są na koncie klienta?

Licencje i zależności

11. Czy istnieje lista wszystkich wtyczek i motywów?
12. Które są premium?
13. Kto posiada każdą licencję?
14. Co przestaje działać po wygaśnięciu?
15. Które wtyczki są krytyczne?
16. Kto odpowiada za aktualizacje?
17. Czy kod custom jest udokumentowany?
18. Czy istnieje repozytorium?
19. Czy można przenieść stronę do innego wykonawcy?
20. Czy przy wyjściu z abonamentu klient zachowuje funkcjonalność bazową?

SEO techniczne

21. Jakie klasy URL-i powinny być indeksowane?
22. Jakie klasy nie powinny?
23. Czy canonical jest spójny z sitemapą i linkami?
24. Czy są łańcuchy przekierowań?
25. Czy istnieją soft 404?
26. Czy robots.txt blokuje coś ważnego?
27. Czy meta robots jest zgodne z intencją strony?
28. Czy sitemap zawiera tylko sensowne URL-e?
29. Czy Search Console pokazuje inne canonicale niż zadeklarowane?
30. Czy są strony osierocone?

HTML i treść

31. Czy główna treść jest dostępna w renderowanym HTML?
32. Czy linki są prawdziwymi <a href>?
33. Czy nagłówki odzwierciedlają strukturę dokumentu?
34. Czy title są unikalne i sensowne?
35. Czy description nie są generowane bezmyślnie z pierwszych 160 znaków?
36. Czy obrazy mają prawidłowe ALT-y?
37. Czy ważne strony mają linki wewnętrzne?
38. Czy nowe artykuły wynikają z realnej luki, czy z abonamentu „8 miesięcznie”?
39. Czy treści mają autora i źródła tam, gdzie to istotne?
40. Czy aktualizuje się stare materiały?

Schema i dane

41. Kto jest właścicielem generowania JSON-LD?
42. Czy kilka pluginów nie produkuje tych samych encji?
43. Czy @id są stabilne?
44. Czy autor w HTML jest tym samym autorem w Schema?
45. Czy cena w HTML zgadza się z Offer?
46. Czy canonical zgadza się z mainEntityOfPage i url?
47. Czy Schema opisuje to, co naprawdę jest widoczne?
48. Czy dane są testowane w Rich Results Test?
49. Czy cały graf jest sprawdzany w Schema.org Validator?
50. Czy błędy structured data mają właściciela i procedurę naprawy?

Link building

51. Czy klient zna każdy pozyskany URL?
52. Czy wie, które publikacje są płatne?
53. Czy raport zawiera anchor, target i rel?
54. Czy linki sponsorowane są odpowiednio oznaczone?
55. Czy agencja pokazuje domeny własnego zaplecza?
56. Czy linki pozostaną po zakończeniu umowy?
57. Czy strategia nie opiera się na niskiej jakości katalogach?
58. Czy ruch/widoczność stron docelowych jest mierzona?
59. Czy linkowanie wewnętrzne zostało uporządkowane przed masowym kupowaniem linków?
60. Czy raportuje się wynik biznesowy, a nie wyłącznie liczbę backlinków?

Raportowanie i odpowiedzialność

61. Co dokładnie zmieniono w tym miesiącu?
62. Na których URL-ach?
63. Dlaczego?
64. Jak zmierzono efekt?
65. Co było testem, a co rutynowym utrzymaniem?
66. Jakie hipotezy nie zadziałały?
67. Jakie błędy są nadal otwarte?
68. Które działania są jednorazowe, a które wymagają abonamentu?
69. Jak wygląda plan na następny miesiąc i z jakich danych wynika?
70. Czy klient może sam zweryfikować raport?

Najbardziej niebezpieczna hiena nie sprzedaje złego SEO. Sprzedaje brak możliwości sprawdzenia SEO

Klient nie musi znać wszystkich systemów rankingowych Google. Nie musi pisać JSON-LD z pamięci. Nie musi umieć programować crawlera. Ale powinien mieć dostęp do własnej infrastruktury i odpowiedź na podstawowe pytania: co zostało zmienione, dlaczego, na jakiej podstawie, jaki był efekt i jak można to odtworzyć.

SEO jest trudne między innymi dlatego, że wyszukiwarka jest systemem zewnętrznym, konkurencja się zmienia, algorytmy się zmieniają, intencje się zmieniają, a dwie podobne strony mogą zareagować inaczej na tę samą modyfikację. To jeszcze jeden powód, żeby nie sprzedawać pewności tam, gdzie istnieje eksperyment.

Profesjonalny wykonawca może powiedzieć:

Nie wiem jeszcze, czy ta zmiana podniesie ruch.

Wiem natomiast:
- dlaczego ją testujemy,
- jaki problem rozwiązuje,
- które URL-e obejmuje,
- jak mierzymy wynik,
- kiedy uznamy test za sukces,
- jak wycofamy zmianę, jeśli wynik będzie negatywny.

Hiena potrzebuje prostszej narracji:

"Poprzednik zrobił źle.
My zrobimy dobrze.
Proszę podpisać abonament."

I właśnie dlatego najlepszą obroną nie jest znajomość wszystkich trików SEO. Jest nią wymaganie jawnego procesu technicznego.