SEO techniczne w czasach GEO, AEO, AIO i A2A

SEO techniczne w czasach GEO / AEO / AIO / A2A. Praktyczny przewodnik krok po kroku aktualny na 03.07.2026

1. Główna zmiana: SEO techniczne nie kończy się już na indeksacji

SEO techniczne przez lata oznaczało głównie: czy Googlebot może wejść na stronę, zaindeksować ją, zrozumieć canonical, przejść po linkach, odczytać sitemapę i ocenić szybkość ładowania. To nadal jest fundament. Ale w 2026 roku dochodzi drugi poziom: czy systemy AI, answer engines i agenci potrafią z tej strony wyciągnąć fakty, relacje, parametry, ograniczenia, dokumenty, dane produktowe i następny krok działania.

Google w dokumentacji dla AI Overviews i AI Mode pisze jasno, że nie ma dodatkowych wymagań technicznych, specjalnego schema ani osobnych plików potrzebnych do pojawienia się w tych funkcjach; strona musi być zaindeksowana, kwalifikować się do wyświetlenia w Google Search ze snippetem i spełniać klasyczne fundamenty SEO. Jednocześnie Google wskazuje, że AI Overviews i AI Mode mogą używać query fan-out, czyli generować wiele powiązanych zapytań do podtematów i źródeł, aby zbudować odpowiedź. To oznacza, że klasyczna indeksowalność jest warunkiem wejścia do gry, ale nie wystarcza do wygrania cytowania, wzmianki lub rekomendacji.

W praktyce nowoczesne SEO techniczne ma trzy cele:

Indeksowalność — strona musi być dostępna, szybka, poprawnie linkowana i zrozumiała dla wyszukiwarek.
Ekstrakcja wiedzy — najważniejsze informacje muszą być łatwe do wyciągnięcia przez systemy AI: definicje, dane, relacje, tabele, FAQ, dokumenty, produkty, autorzy.
Gotowość agentowa — strona i dane muszą umożliwiać wykonanie zadania: porównanie, wybór, zapytanie ofertowe, rezerwację, zakup, pobranie dokumentu, kontakt lub integrację przez API.

2. Definicje robocze: SEO, GEO, AEO, AIO i A2A

Na potrzeby wdrożenia warto uporządkować pojęcia:

SEO — klasyczna optymalizacja pod wyszukiwarki: crawling, indeksacja, architektura informacji, linkowanie, canonicale, sitemap, szybkość, treść, dane strukturalne i jakość strony.

GEO — Generative Engine Optimization, czyli przygotowanie treści i danych tak, aby systemy generatywne mogły zacytować stronę, użyć jej jako źródła lub wymienić markę w odpowiedzi.

AEO — Answer Engine Optimization, czyli budowanie treści w formie jasnych odpowiedzi: definicji, sekcji Q&A, porównań, tabel, checklist i fragmentów, które można bezpiecznie wykorzystać w odpowiedzi.

AIO — w praktyce dwa znaczenia: AI Overviews w Google oraz szerzej AI Optimization, czyli przygotowanie marki, strony, dokumentów, danych i profili zewnętrznych pod widoczność w środowiskach AI.

A2A — Agent-to-Agent / Agentic workflows. To etap, w którym agent użytkownika lub agent firmowy nie tylko czyta stronę, ale próbuje wykonać zadanie: zebrać dane, porównać dostawców, przygotować RFQ, sprawdzić dostępność, zapytać o termin lub połączyć się z narzędziem. Google ogłosił Agent2Agent Protocol jako standard komunikacji agentów, a MCP jest opisywany jako otwarty standard łączenia aplikacji AI z zewnętrznymi danymi, narzędziami i workflow. To nie jest jeszcze klasyczny „czynnik SEO”, ale już jest kierunek technicznej gotowości stron i systemów.

3. Najważniejsza zasada na 2026: nie buduj „strony dla AI”, tylko stronę źródłową

Google ostrzega przed myśleniem, że trzeba tworzyć specjalne pliki AI, specjalny markup lub osobny styl tekstu tylko po to, aby pojawić się w AI Overviews lub AI Mode. Według Google najlepsze praktyki SEO nadal są aktualne: crawlability, linkowanie wewnętrzne, dobra jakość strony, tekstowa dostępność ważnych informacji, wysokiej jakości obrazy i wideo, zgodność structured data z widoczną treścią oraz aktualne dane Merchant Center i Business Profile.

Dlatego nie chodzi o „magiczne techniczne SEO pod AI”. Chodzi o to, aby strona była:

dostępna dla crawlerów,
szybka i stabilna,
semantycznie uporządkowana,
oparta o tekst, dane i dokumenty,
zrozumiała jako graf encji,
dobrze linkowana wewnętrznie,
zgodna z danymi strukturalnymi,
aktualna,
gotowa do cytowania,
gotowa do porównania,
gotowa do działania przez człowieka lub agenta.

4. Nowa matryca SEO technicznego

Obszar	Klasyczne SEO techniczne	SEO techniczne 2026+ dla GEO / AEO / AIO / A2A
Cel	Indeksacja i ranking	Bycie źródłem wiedzy, cytowania, danych i działań
Bot	Googlebot, Bingbot	Googlebot, OAI-SearchBot, GPTBot, PerplexityBot, Applebot, ClaudeBot, agenci użytkowników
Treść	Strony HTML	Strony źródłowe, dane, tabele, FAQ, dokumenty, feedy, API
Schema	Rich snippets	Disambiguacja encji, produkty, organizacja, usługi, autorzy, dokumenty
Szybkość	UX i ranking	UX, crawl budget, ekstrakcja danych, gotowość do AI retrieval
Sitemap	Odkrywanie URL-i	Odkrywanie kanonicznych, aktualnych stron źródłowych
Robots.txt	Zarządzanie crawl budgetem	Polityka dostępu dla search, AI-input, AI-training i botów agentowych
Canonical	Kontrola duplikacji	Jedno źródło prawdy dla encji, produktu i dokumentu
Linkowanie	Przepływ autorytetu	Graf relacji: problem → rozwiązanie → produkt → dokument → kontakt
API / feed	Głównie e-commerce	Warstwa agent-ready: produkt, cena, dostępność, RFQ, status, dokumenty

5. Krok 1: crawlability — najpierw upewnij się, że strona może być odkryta

Jeżeli strona nie jest dostępna dla crawlerów, nie ma SEO, GEO ani AIO. Google wskazuje, że aby strona mogła być linkiem wspierającym w AI Overviews lub AI Mode, musi być zaindeksowana i kwalifikować się do pokazania w Google Search ze snippetem. Google podkreśla też, że crawling musi być dozwolony w robots.txt oraz w warstwie CDN/hostingu.

Minimalna checklista:

strona zwraca HTTP 200,
nie jest zablokowana w robots.txt,
nie ma przypadkowego noindex,
canonical wskazuje właściwy URL,
jest w sitemapie,
jest linkowana wewnętrznie,
nie wymaga logowania,
nie wymaga zgody cookies do wyświetlenia głównej treści,
główna treść jest dostępna w HTML,
bot nie dostaje innej, uboższej wersji niż użytkownik,
CDN/WAF nie blokuje legalnych crawlerów,
formularze i wyszukiwarki wewnętrzne nie są jedyną drogą do treści.

Przykładowy minimalny robots.txt:

User-agent: *
Allow: /

Sitemap: https://example.com/sitemap.xml

Dla większych stron nie wystarczy samo Allow: /. Trzeba sprawdzić, czy szablony, filtry, parametry, zasoby JS/CSS, obrazy, PDF-y i feedy nie są blokowane przypadkiem.

6. Krok 2: zarządzanie botami AI — nie wrzucaj wszystkich do jednego worka

W 2026 roku robots.txt jest nie tylko plikiem dla Googlebota. Stał się polityką dostępu dla różnych typów botów: search, AI search, training, user-triggered browsing i agentów. Google przypomina, że robots.txt jest mechanizmem zarządzania ruchem crawlerów, ale nie zabezpiecza prywatnych danych; crawler musi dobrowolnie respektować reguły, więc dane wrażliwe należy chronić hasłem, uprawnieniami lub inną kontrolą dostępu.

Najważniejsze rozróżnienie:

boty wyszukiwarkowe — budują indeks i wpływają na widoczność,
boty AI search — mogą zasilać odpowiedzi i cytowania,
boty treningowe — pobierają dane do trenowania lub ulepszania modeli,
user agents / user-triggered fetchers — działają na żądanie użytkownika,
scrapery niezgodne z robots.txt — mogą ignorować reguły.

OpenAI dokumentuje osobne crawlery i user-agenty oraz wskazuje, że webmasterzy mogą używać tagów OAI-SearchBot i GPTBot w robots.txt do zarządzania tym, jak strona współpracuje z produktami AI. To ważne, bo GPTBot nie powinien być traktowany tak samo jak OAI-SearchBot: pierwszy jest kojarzony z pobieraniem publicznych treści do ulepszania modeli, a drugi z wyszukiwaniem i pobieraniem źródeł dla produktów OpenAI.

Perplexity również dokumentuje własne crawlery i wskazuje, że webmasterzy mogą zarządzać interakcją z Perplexity przez tagi robots.txt, przy czym poszczególne ustawienia działają niezależnie, a zmiany mogą wymagać czasu na odzwierciedlenie w systemach.

Apple opisuje Applebot jako crawler zasilający wyszukiwanie w ekosystemie Apple, m.in. Spotlight, Siri i Safari; włączenie Applebot w robots.txt umożliwia pojawianie się treści w doświadczeniach wyszukiwania Apple. Applebot-Extended służy osobno do rezygnacji z użycia treści do trenowania modeli Apple Intelligence, bez prostego utożsamiania go z klasycznym search.

Przykładowa polityka dla firmy, która chce być widoczna w wyszukiwaniu i AI search, ale chce ograniczać trening tam, gdzie to możliwe:

# Klasyczne wyszukiwanie
User-agent: Googlebot
Allow: /

User-agent: Bingbot
Allow: /

User-agent: Applebot
Allow: /

# OpenAI Search – widoczność w wyszukiwaniu/cytowaniach OpenAI
User-agent: OAI-SearchBot
Allow: /

# OpenAI training – decyzja strategiczna
User-agent: GPTBot
Disallow: /

# Perplexity – decyzja strategiczna
User-agent: PerplexityBot
Allow: /

# Common Crawl – decyzja strategiczna
User-agent: CCBot
Disallow: /

Sitemap: https://example.com/sitemap.xml

To tylko przykład. Nie ma jednej uniwersalnej konfiguracji. Portal medialny, sklep, firma B2B, SaaS, marketplace i baza wiedzy mogą mieć różną politykę. Najgorsza decyzja to przypadkowe blokowanie wszystkiego albo przypadkowe wpuszczanie wszystkiego bez świadomości skutków.

7. Krok 3: Google-Extended nie jest przełącznikiem AI Overviews

Wiele firm myli Google-Extended z kontrolą widoczności w AI Overviews. To błąd. Google w dokumentacji AI features wskazuje, że AI jest częścią Search, a kontrolą dostępu dla Google Search pozostaje Googlebot. Aby ograniczyć informacje pokazywane z Twoich stron w Search, trzeba używać nosnippet, data-nosnippet, max-snippet albo noindex; Google-Extended dotyczy ograniczania AI training i grounding w niektórych innych systemach Google.

W praktyce:

jeżeli zablokujesz Googlebot, możesz stracić klasyczną widoczność w Google i widoczność jako link wspierający w AI Overviews / AI Mode;
jeżeli użyjesz nosnippet, możesz ograniczyć możliwość pokazania treści jako snippet i wpływać na kwalifikację do AI features;
jeżeli użyjesz Google-Extended, nie jest to prosty sposób na wyłączenie AI Overviews;
jeżeli chcesz kontrolować konkretne fragmenty, używaj data-nosnippet ostrożnie;
jeżeli chcesz chronić dane prywatne, nie polegaj na robots.txt — użyj autoryzacji.

8. Krok 4: kontrola snippetów — techniczna decyzja biznesowa

Google wskazuje, że do ograniczania informacji pokazywanych w AI features w Search można stosować nosnippet, data-nosnippet, max-snippet i noindex. To oznacza, że preview controls są dziś narzędziem nie tylko klasycznego SEO, ale również kontroli udziału treści w AI Overviews i AI Mode.

Przykład:

<meta name="robots" content="max-snippet:160">

Lub fragmentowo:

<p>Ten fragment może być użyty jako snippet.</p>

<p data-nosnippet>
  Ten fragment nie powinien być używany jako snippet w Google Search.
</p>

Praktyczna zasada:

nie używaj nosnippet globalnie na stronach, które mają być cytowane;
nie używaj data-nosnippet na kluczowych definicjach, parametrach i odpowiedziach;
używaj data-nosnippet dla fragmentów wrażliwych, prawnych, cen tymczasowych, danych osobowych lub treści, które nie powinny być wyrywane z kontekstu;
dla stron przychodowych sprawdź, czy polityka snippetów nie blokuje widoczności w AI features.

9. Krok 5: canonical — jedno źródło prawdy dla encji

Canonical nie jest tylko problemem duplikacji. W czasach AI Search canonical wskazuje, która strona jest głównym źródłem prawdy dla produktu, usługi, dokumentu, artykułu lub encji. Google opisuje canonicalizację jako proces wyboru reprezentatywnego URL-a dla zduplikowanych lub podobnych treści i wskazuje, że właściciel strony może sygnalizować preferowany canonical różnymi metodami, choć Google może ostatecznie wybrać inny URL.

W praktyce:

każda encja powinna mieć jeden URL kanoniczny;
warianty produktu powinny mieć jasną logikę canonicali;
strony z parametrami i filtrami nie powinny rozmywać sygnałów;
wersje językowe powinny mieć spójny canonical i hreflang;
PDF nie powinien być jedyną wersją treści, jeśli HTML ma być źródłem cytowania;
strona dokumentu powinna linkować do produktu, a produkt do dokumentu.

Przykład:

<link rel="canonical" href="https://example.com/produkty/system-x/">

Dla AI i wyszukiwarek chaos canonicali oznacza chaos wiedzy: system może nie wiedzieć, która strona jest źródłem aktualnej specyfikacji, ceny, instrukcji lub dokumentu.

10. Krok 6: sitemap — mapa aktualnych źródeł, nie śmietnik URL-i

Google wspiera różne formaty sitemap i zaleca umieszczać w sitemapie preferowane, kanoniczne URL-e. Sitemap można zgłosić przez Search Console, API albo wskazać w robots.txt; Google zaznacza jednak, że zgłoszenie sitemap jest wskazówką, a nie gwarancją pobrania lub crawlowania wszystkich adresów.

Sitemap w 2026 powinna zawierać:

tylko strony kanoniczne,
tylko strony zwracające 200,
tylko strony indeksowalne,
aktualne strony produktów, usług, kategorii, poradników, dokumentów,
prawdziwe daty lastmod,
osobne sitemapy dla produktów, artykułów, dokumentów, obrazów, wideo, wersji językowych,
plik sitemap index dla większych serwisów.

Przykład:

<url>
  <loc>https://example.com/produkty/system-x/</loc>
  <lastmod>2026-07-03</lastmod>
</url>

Nie fałszuj lastmod. Jeżeli zmieniła się tylko liczba odsłon, nie jest to aktualizacja merytoryczna. Jeśli zmieniły się parametry, dostępność, dokumenty, cena, regulacje, FAQ lub sekcja decyzyjna — to jest aktualizacja istotna.

11. Krok 7: JavaScript — ważne treści powinny być dostępne bez zgadywania

Google dokumentuje, że przetwarza aplikacje JavaScript w trzech fazach: crawling, rendering i indexing. Google Search używa renderowania opartego o Chromium, ale nadal warto optymalizować aplikacje JS pod odkrywalność i indeksowanie.

W kontekście GEO/AEO/AIO/A2A zasada jest jeszcze prostsza:

najważniejszy tekst powinien być w HTML lub renderowany po stronie serwera,
linki wewnętrzne powinny być klasycznymi linkami <a href="">,
dane strukturalne powinny być obecne i zgodne z widoczną treścią,
parametry produktu nie powinny być ukryte wyłącznie w JS,
FAQ nie powinno ładować się tylko po interakcji,
tabele danych powinny być w HTML, nie jako obraz,
formularz RFQ powinien działać bez niestabilnych skryptów,
crawlery AI, które nie renderują pełnego JS, powinny nadal zobaczyć najważniejsze informacje.

Dla stron B2B, e-commerce i dokumentacyjnych najlepszą praktyką jest SSR, SSG albo przynajmniej pre-render dla stron przychodowych, produktowych, kategorii i poradników źródłowych.

12. Krok 8: semantyczny HTML — mniej ozdobników, więcej struktury

Modele i ekstraktory treści muszą odróżnić główną treść od menu, stopki, banerów, reklam i elementów dekoracyjnych. Badanie WCXB z 2026 roku pokazuje, że ekstrakcja głównej treści jest podstawą indeksowania, RAG i budowy datasetów NLP, a systemy ekstrakcji radzą sobie znacznie gorzej z typami stron innymi niż klasyczne artykuły, np. produktami, listingami, dokumentacją i stronami usług.

Dlatego techniczne SEO powinno pilnować semantycznego HTML:

<main>
  <article>
    <header>
      <h1>Jak wybrać system X dla firmy produkcyjnej?</h1>
      <p>Krótka odpowiedź...</p>
    </header>

    <section>
      <h2>Kiedy system X ma sens?</h2>
      <p>...</p>
    </section>

    <section>
      <h2>Najważniejsze kryteria wyboru</h2>
      <table>
        <thead>
          <tr><th>Kryterium</th><th>Co sprawdzić</th></tr>
        </thead>
        <tbody>
          <tr><td>Wolumen</td><td>Liczba jednostek dziennie</td></tr>
        </tbody>
      </table>
    </section>
  </article>
</main>

Najważniejsze elementy:

jedno H1 na temat strony,
logiczne H2/H3,
definicja na początku,
krótkie odpowiedzi pod pytaniami,
tabele dla porównań,
listy dla checklist,
article, section, aside, nav, header, footer,
tekstowe podpisy pod obrazami,
linki opisowe, nie „kliknij tutaj”,
brak ukrywania kluczowych informacji w karuzelach i accordionach bez tekstowej alternatywy.

13. Krok 9: struktura answer-first — AEO zaczyna się w kodzie

AEO nie jest tylko stylem pisania. To techniczna struktura strony. Każda ważna strona powinna mieć fragment, który odpowiada bezpośrednio na pytanie użytkownika.

Format:

<section>
  <h2>Czy rozwiązanie X ma sens dla małej firmy?</h2>
  <p>
    Rozwiązanie X ma sens, gdy firma ma powtarzalny proces, mierzalny wolumen
    i potrzebuje ograniczyć pracę ręczną. Nie wystarczy jednak, gdy proces jest
    skrajnie nieregularny lub brakuje danych do doboru.
  </p>
</section>

Dobra odpowiedź technicznie:

zaczyna się od jasnego zdania,
nie wymaga przeczytania całej strony,
zawiera warunki,
zawiera ograniczenia,
prowadzi do następnego kroku,
linkuje do produktu, dokumentu lub formularza.

14. Krok 10: Schema.org — warstwa porządkująca, nie magiczny ranking

Dane strukturalne pomagają Google zrozumieć zawartość strony i klasyfikować jej treść. Google zaznacza, że większość danych strukturalnych w Search używa słownika Schema.org, ale dla zachowania Google Search należy opierać się na dokumentacji Google Search Central.

W SEO technicznym 2026 warto wdrożyć przynajmniej:

Organization / LocalBusiness,
Product,
Offer,
Service,
Article,
FAQPage,
HowTo, gdy faktycznie opisujesz procedurę,
BreadcrumbList,
Person,
VideoObject,
ImageObject,
CollectionPage,
DefinedTerm,
ContactPage,
AboutPage.

Google w dokumentacji Organization wskazuje, że dane organizacji na stronie głównej lub stronie „O nas” pomagają lepiej zrozumieć dane administracyjne organizacji i odróżnić ją od innych podmiotów; niektóre pola, jak iso6523 i naics, mogą działać za kulisami jako element disambiguation, a inne wpływać na elementy wizualne, np. logo.

Przykład uproszczonego Organization:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "Example Company",
  "url": "https://example.com/",
  "logo": "https://example.com/logo.png",
  "description": "Dostawca rozwiązań technicznych dla firm B2B.",
  "contactPoint": {
    "@type": "ContactPoint",
    "contactType": "sales",
    "email": "kontakt@example.com",
    "areaServed": "PL"
  },
  "sameAs": [
    "https://www.linkedin.com/company/example-company"
  ]
}
</script>

15. Krok 11: schema musi zgadzać się z widoczną treścią

Google wyraźnie wskazuje, że structured data powinno pasować do widocznego tekstu na stronie. W dokumentacji AI features Google wymienia zgodność danych strukturalnych z widoczną treścią jako jedną z praktyk SEO istotnych także dla AI Overviews i AI Mode.

Błędy:

schema mówi o produkcie, którego nie ma na stronie,
cena w schema różni się od ceny widocznej,
FAQPage zawiera pytania niewidoczne dla użytkownika,
Organization ma stare dane kontaktowe,
Product ma nieaktualną dostępność,
autor w schema nie istnieje na stronie,
strona ma Review, ale użytkownik nie widzi recenzji.

Zasada: schema ma potwierdzać treść, nie ją zastępować.

16. Krok 12: Product, Merchant Center i feedy — dane produktowe są technicznym SEO

Dla sklepów, marketplace’ów i firm B2B z katalogiem produktów dane produktowe są dziś częścią SEO technicznego. Google wskazuje, że połączenie danych strukturalnych na stronie i feedu Merchant Center może maksymalizować kwalifikowalność do doświadczeń produktowych oraz pomagać Google poprawnie zrozumieć i zweryfikować dane.

Minimalny zestaw danych produktowych:

nazwa produktu,
model,
marka / producent,
kategoria,
opis zastosowania,
parametry techniczne,
zdjęcia,
cena lub model wyceny,
dostępność,
waluta,
warianty,
dokumenty,
instrukcje,
kompatybilne akcesoria,
branże,
region obsługi,
dane do zapytania ofertowego.

Google Merchant Center wskazuje, że dokładne i poprawnie sformatowane dane produktowe są kluczowe, ponieważ Google używa ich do dopasowywania produktów do zapytań, a błędne dane mogą powodować problemy z zatwierdzeniem lub wyświetlaniem.

Dla A2A warto mieć dodatkowo eksport w formacie JSON/CSV/XML, który pozwoli agentowi lub systemowi zakupowemu pobrać aktualne dane.

17. Krok 13: dane do RFQ — ukryty element technicznego SEO B2B

W B2B strona często nie kończy się koszykiem, tylko zapytaniem ofertowym. Dlatego techniczne SEO powinno przygotować stronę pod RFQ i agentic commerce.

Strona „Dane do wyceny” powinna zawierać:

co firma oferuje,
dla jakich branż,
jakie parametry trzeba podać,
jakie zdjęcia lub dokumenty warto załączyć,
jakie są typowe zakresy zastosowań,
jakie są ograniczenia,
jakie dokumenty można otrzymać,
jak wygląda proces testu,
jak wygląda proces serwisu,
formularz,
adres email,
telefon,
plik do pobrania,
wersję JSON lub tabelę danych.

Przykładowy blok danych do RFQ:

<section id="rfq-data">
  <h2>Dane potrzebne do wyceny</h2>
  <ul>
    <li>Branża i typ procesu</li>
    <li>Wolumen dzienny lub miesięczny</li>
    <li>Wymiary produktu / opakowania</li>
    <li>Obecny sposób realizacji procesu</li>
    <li>Oczekiwany cel: koszt, szybkość, zgodność, automatyzacja</li>
    <li>Wymagania dokumentacyjne</li>
    <li>Termin wdrożenia</li>
  </ul>
</section>

To jest jednocześnie SEO, AEO i A2A: człowiek wie, co wysłać, a agent wie, jakie dane zebrać.

18., co wysłać, a agent wie, jakie dane zebrać.

18. Krok 14: świeżość danych — aktualizacja musi być technicznie widoczna

AI Search jest szczególnie wrażliwy na aktualność przy cenach, dostępności, regulacjach, produktach, dokumentach i wydarzeniach. Google AI Mode i AI Overviews mogą korzystać z wielu zapytań i źródeł, a Google podkreśla, że AI Mode jest przydatny przy ekspi dalszym zgłębianiu tematów. citeturn684749view2

Technicznie warto wdrożyć:

prawdziwy lastmod w sitemapie,
datę aktualizacji na stronie,
wersjonowanie dokumentów,
aktualizowane dane Product/Offer,
Merchant Center dla produktów,
cache invalidation po zmianach,
nagłówki Last-Modified i ETag,
osobną sitemapę dla często zmienianych zasobów,
changelog dla ważnych poradników,
monitoring nieaktualnych dat w schema.

Przykład HTTP:

Last-Modified: Fri, 03 Jul 2026 08:00:00 GMT
ETag: "product-x-v2026-07-03"
Cache-Control: public, max-age=3600

Nie chodzi o udawanie świeżości. Chodzi o to, aby realne zmiany były widoczne technicznie.

19. Krok 15: IndexNow i Google Indexing API — używaj świadomie

IndexNow to protokół umożliwiający właścicielom stron natychmiastowe informowanie uczestniczących wyszukalizacji lub usunięciu URL-a. citeturn684749view5

Trzeba jednak rozdzielić IndexNow od Google. Google Indexing API nie jest uniwersalnym narzędziem do indeksowania wszystkich stron. Oficjalna dokumentacja Google mówi, że Indexing API można używać tylko dla stron z JobPostint osadzonym w VideoObject. citeturn684749view6

Praktycznie:

używaj IndexNow dla Bing i innych uczestniczących wyszukiwarek,
nie obiecuj klientom „natychmiastowego indeksowania w Google” przez IndexNow,
Google: sitemap, linkowanie wewnętrzne, Search Console, jakość strony, crawlability,
Indexing API Google: tylko dopuszczone typy stron,
dla produktów: Merchant Center i aktualne dane,
dla newsów/wideo: odpowiednie sitemapy i schema.

20. Krok 16: Core Web Vitals — szybkość to nie tylko ranking, ale dostępność danych

Google definiuje Core Web Vitals jako metryki realnego doświadczenia użytkownika: LCP dla ładowania, INP dla responsywności i CLS dla stabilności wizualnej. Google rekomenduje dobre Core Web Vitals dla sukcesu w Search i dobrego UX, wskazując progi: ej 200 ms i CLS poniżej 0,1. citeturn684749view12

W czasach AI Search szybkość ma dodatkowe znaczenie:

szybciej dostępny HTML,
niższy koszt crawl,
mniej timeoutów botów,
lepszy UX po kliknięciu z AI Overview,
większa szansa na konwersję,
lepsza dostępność dla agentów,
mniej problemów z renderowaniem.

Priorytety:

SSR/SSG dla stron strategicznych,
krytyczny CSS,
optymalizacja obrazów,
lazy loading z zachowaniem dostępności,
ograniczenie ciężkich skryptów,
eliminacja layout shift,
optymalizacja fontów,
CDN,
cache,
ograniczenie zewnętrznych tagów na stronach przychodowych.

21. Krok 17: obrazy i wideo — multimodalne SEO techniczne

Google wskazuje w dokumentacji AI features, że warto wspierać treść tekstowązami i wideo, gdy ma to sens. citeturn684749view2

Dla SEO technicznego oznacza to:

opisowe nazwy plików,
tekst alternatywny,
podpisy pod zdjęciami,
transkrypcje wideo,
VideoObject,
ImageObject,
miniatury,
sitemap image/video, jeśli zasadne,
tekstowe streszczenie filmu na stronie,
zdjęcia produktu w użyciu, nie tylko packshot,
schematy procesów opisane tekstem.

Przykład:

<figure>
  <img src="/images/system-x-linia-produkcyjna.webp"
       alt="System X zastosowany w linii produkcyjnej do automatyzacji procesu pakowania">
  <figcaption>
    System X w linii produkcyjnej: automatyzacja powtarzalnego etapu procesu.
  </figcaption>
</figure>

Dla agentów i AI obraz bez opisu to słaby sygnał. Obraz z podpisem i kontekstem staje się elementem wiedzy.

22. Krok 18: dokumenty PDF — nie zostawiaj wiedzy poza HTML

PDF-y są potrzebne, ale nie powinny być jedynym miejscem, gdzie istnieją ważne fakty. AI, crawler i użytkownik powinni mieć stronę HTML opisującą dokument.

Strona dokumentu powinna zawierać:

nazwę dokumentu,
typ dokumentu,
datę,
wersję,
wystawcę,
produkt lub usługę, której dotyczy,
właściwości, które potwierdza,
właściwości, których nie potwierdza,
ograniczenia interpretacji,
link do produktu,
link do pobrania,
kontakt.

Przykład struktury:

<article>
  <h1>Deklaracja zgodności dla produktu X</h1>
  <p>Dokument dotyczy produktu X i potwierdza wybrane parametry techniczne...</p>

  <h2>Jakiego produktu dotyczy dokument?</h2>
  <p>...</p>

  <h2>Co dokument potwierdza?</h2>
  <ul>...</ul>

  <h2>Ograniczenia interpretacji</h2>
  <p>...</p>

  <a href="/docs/deklaracja-produkt-x.pdf">Pobierz dokument PDF</a>
</article>

To szczególnie ważne dla B2B, regulacji, zakupów, compliance i dokumentacji materiałowej.

23. Krok 19: linkowanie wewnętrzne jako graf wiedzy

Google wskazuje, że w AI Overviews i AI Mode modele mogą identyfikować dodatkowe strony wspierające odpowiedź, a query fan-out może prowadzić do sw niż klasyczne wyszukiwanie. citeturn684749view2

Dlatego linkowanie wewnętrzne powinno wyglądać jak graf:

problem → rozwiązanie,
rozwiązanie → produkt,
produkt → dokument,
dokument → produkt,
produkt → case study,
case study → formularz,
słownik → poradnik,
poradnik → kategoria,
kategoria → produkt,
produkt → porównanie,
porównanie → dane do wyceny.

Przykład anchorów:

„jak dobrać rozwiązanie do wolumenu”
„dokumentacja techniczna produktu X”
„porównanie X i Y”
„dane potrzebne do zapytania ofertowego”
„zastosowanie w branży produkcyjnej”
„najczęstsze błędy przy wdrożeniu”

Unikaj anchorów typu „więcej”, „kliknij”, „tutaj”. One nie budują relacji.

24. Krok 20: architektura hubów — odpowiedź na query fan-out

AI Mode i AI Overviews mogą rozbe podzapytań. citeturn684749view2turn684749view3

Dlatego strona potrzebuje hubów tematycznych:

Hub główny: temat strategiczny
Podstrony:

definicja,
dla kogo,
jak wybrać,
X vs Y,
dokumenty,
FAQ,
koszt,
wdrożenie,
błędy,
case study,
produkty,
dane do RFQ,
kontakt.

Przykład anonimowy:

/hub-proces-x/
/hub-proces-x/co-to-jest/
/hub-proces-x/jak-wybrac/
/hub-proces-x/x-vs-y/
/hub-proces-x/dokumenty/
/hub-proces-x/checklista-rfq/
/produkty/produkt-x/
/uslugi/wdrozenie-procesu-x/

Taki układ daje systemowi AI wiele punktów wejścia i pomaga połączyć temat z ofertą.

25. Krok 21: entity SEO — techniczne SEO musi opisywać byty

Entity optimization to nie tylko content. To technika:

@id w JSON-LD,
spójne nazwy,
sameAs,
linkowanie do profili,
strony źródłowe,
breadcrumbs,
canonicale,
dane organizacji,
dane produktów,
autorzy,
dokumenty,
relacje między stronami.

Przykład @id:

"@id": "https://example.com/#organization"

Dzięki temu różne fragmenty schema mogą odnosić się do tej samej encji:

"publisher": {
  "@id": "https://example.com/#organization"
}

To pomaga utrzymać spójność między artykułami, produktami, usługami i stroną organizacji.

26. Krok 22: `sameAs` — tylko dla prawdziwej tożsamości

sameAs w Schema.org oznacza URL strony referencyjnej, która jednoznacznie wskazuje tożsamość danej rzeczych linków „zobacz także”. citeturn226335search17

Stosuj sameAs do:

oficjalnych profili social media,
profilu LinkedIn firmy,
wiarygodnych katalogów,
Wikidata/Wikipedia, jeśli istnieją i są poprawne,
oficjalnych profili autora,
stron producenta/partnera, jeśli rzeczywiście identyfikują podmiot.

Nie używaj sameAs do:

przypadkowych artykułów,
wpisów blogowych,
konkurencji,
niezweryfikowanych katalogów,
stron, które nie potwierdzają tożsamości.

27. Krok 23: E-E-A-T technicznie — autor, firma, data, dowód

Wysoka wiarygodność nie wynika tylko z tekstu. Technicznie można ją wzmocnić przez:

stronę autora,
schema Person,
stronę organizacji,
schema Organization,
datę publikacji,
datę aktualizacji,
wersję dokumentu,
linki do źródeł,
linki do dokumentów,
zastrzeżenia przy tematach regulacyjnych,
widoczny kontakt,
politykę redakcyjną,
strony case studies,
zdjęcia i filmy z realnego użycia.

Przykład:

<p>
  Autor merytoryczny: Jan Kowalski, specjalista ds. wdrożeń technicznych.
  Aktualizacja: 03.07.2026.
</p>

I w schema:

"dateModified": "2026-07-03",
"author": {
  "@type": "Person",
  "name": "Jan Kowalski"
}

28. Krok 24: strona „dla agentów AI” — praktyczny element A2A

Nie trzeba od razu budować pełnego A2A endpointu. Wiele firm powinno zacząć od prostej strony HTML, która porządkuje dane dla użytkownika, działu zakupów i agenta AI.

Struktura strony:

Kim jesteśmy.
Co oferujemy.
Dla jakich branż.
Jakie problemy rozwiązujemy.
Jakie dane są potrzebne do doboru / wyceny.
Jakie dokumenty możemy dostarczyć.
Jakie są ograniczenia oferty.
Jak wygląda proces kontaktu.
Dane kontaktowe.
Linki do kategorii.
Linki do dokumentów.
Link do formularza RFQ.
Aktualizacja strony.

Przykład URL:

/dla-agentow-ai/
/dane-do-wyceny/
/rfq/

To nadal normalna strona dla ludzi. Różnica polega na tym, że jest zaprojektowana tak, aby agent też mógł ją szybko zrozumieć.

29. Krok 25: API i feedy — druga warstwa agent-ready

Dla firm z produktami, dostępnością, konfiguratorami, rezerwacjami, terminami, magazynem lub cenami warto przygotować warstwę danych.

Minimum:

feed produktowy,
feed dostępności,
feed dokumentów,
endpoint statusu produktu,
OpenAPI spec dla publicznych endpointów,
przykładowe zapytanie RFQ,
jasne limity i autoryzacja,
kontakt techniczny,
polityka korzystania z danych.

Przykładowe dane produktu w JSON:

{
  "product_id": "X-100",
  "name": "Produkt X 100",
  "category": "Systemy techniczne",
  "application": ["produkcja", "magazyn", "B2B"],
  "availability": "on_request",
  "documents": [
    {
      "type": "technical_datasheet",
      "url": "https://example.com/docs/x-100-datasheet.pdf",
      "date": "2026-07-03"
    }
  ],
  "rfq_required_fields": [
    "industry",
    "volume_per_day",
    "current_process",
    "target"
  ]
}

To nie zastępuje SEO. To przygotowuje firmę na agentic workflows.

30. Krok 26: A2A i MCP — ostrożnie z obietnicami

Agent2Agent Protocol jest rozwijany jako standard komunikacji agentów, a MCP jako standard łączenia aplikacji AI z zewnętrznymi systemami. To ważny kierunek, ale w praktyce większość stron firmowych nrotokołu A2A. citeturn684749view7turn684749view8

Priorytet dla firm:

uporządkowany HTML,
schema,
dane produktowe,
feedy,
dokumentacja,
formularz RFQ,
OpenAPI dla realnych funkcji,
autoryzacja i bezpieczeństwo,
dopiero potem eksperymenty z agentami.

Nie obiecuj klientom, że „wdrożenie A2A da pozycje w Google”. Lepiej mówić: „wdrożenie agent-ready data layer ułatwia przyszłym agentom porównywanie, pobieranie danych i inicjowanie zapytań”.

31. Krok 27: bezpieczeństwo agentów i danych

Im bardziej strona jest agent-ready, tym bardziej trzeba myśleć o bezpieczeństwie.

Zasady:

nie wystawiaj prywatnych danych w publicznym feedzie,
oddziel dane publiczne od danych dla zalogowanych partnerów,
używaj rate limitów,
loguj ruch agentów,
rozróżniaj boty znane i nieznane,
stosuj WAF,
wymagaj autoryzacji dla zapytań transakcyjnych,
nie pozwalaj agentowi wykonywać kosztownych działań bez potwierdzenia,
waliduj dane z formularzy,
zabezpiecz endpointy API.

Badania nad emerging AI-agent protocols wskazują, że MCP, A2A i podobne protokoły mają nowe powierzchnie ryzyka, m.in. związane z zaufaniem, walidacją komponentócyklem życia integracji. citeturn112366academia46

32. Krok 28: logi serwera — nowe źródło prawdy

W 2026 roku analiza logów powinna obejmować nie tylko Googlebota. Trzeba sprawdzać:

Googlebot,
Bingbot,
OAI-SearchBot,
GPTBot,
PerplexityBot,
Applebot,
ClaudeBot / Claude-SearchBot,
CCBot,
nieznane user-agenty,
IP i ASN,
statusy HTTP,
częstotliwość crawlowania,
ścieżki wejścia,
blokady WAF,
timeouty,
crawl na PDF-ach,
crawl na feedach,
crawl na stronach przychodowych.

Przykładowe pytania:

Czy AI boty widzą strony, które chcemy im pokazać?
Czy crawl nie idzie tylko po śmieciowych parametrach?
Czy ważne produkty są odwiedzane?
Czy dokumenty są pobierane?
Czy bot dostaje 403/429/5xx?
Czy CDN nie blokuje legalnych crawlerów?
Czy boty trenujące są oddzielone od botów search?

33. Krok 29: monitoring odpowiedzi AI jako element technicznego SEO

Google informuje, że strony pojawiające się w AI features są raportowane w Search Console w ramach ogólnego ruchu Search, w typie „Web”; warto też łączyć Search Console z Analyticoraz zachowanie użytkowników. citeturn684749view2

Ale to nie wystarczy. Trzeba prowadzić ręczny lub półautomatyczny monitoring promptów.

Dla każdej ważnej kategorii testuj:

„co to jest X?”,
„jak wybrać X dla firmy Y?”,
„X vs Y — co wybrać?”,
„kto dostarcza X w Polsce?”,
„jakie dokumenty sprawdzić przed wyborem X?”,
„przygotuj checklistę RFQ dla X”,
„porównaj dostawców X”.

Zapisuj:

czy marka jest wymieniona,
czy strona jest cytowana,
jakie źródła są cytowane,
czy AI rozumie kategorię,
czy dane są aktualne,
czy są błędy,
czy konkurencja ma lepszą stronę źródłową,
która strona powinna zostać poprawiona.

34. Krok 30: najważniejsze błędy techniczne w erze GEO/AIO

Błąd 1: blokowanie botów bez strategii

Firma blokuje GPTBot, OAI-SearchBot, PerplexityBot, Applebot i inne boty jedną regułą, a potem dziwi się, że nie jest widoczna w odpowiedziach AI.

Błąd 2: treść tylko w JavaScript

Google może renderować JS, ale nie każdy crawler i agent zrobi to tak samo. Strategiczne treści powinny być dostępne w HTML.

Błąd 3: schema niezgodne z treścią

To osłabia zaufanie i może powodować błędy interpretacji.

Błąd 4: PDF jako jedyne źródło informacji

Produkt, certyfikat lub deklaracja istnieje tylko w pliku, bez strony HTML.

Błąd 5: chaos canonicali

AI i Google nie wiedzą, która wersja strony jest głównym źródłem prawdy.

Błąd 6: brak stron decyzyjnych

Strona odpowiada „co to jest?”, ale nie odpowiada „czy to ma sens w mojej sytuacji?”.

Błąd 7: brak danych do działania

Agent lub kupujący nie wie, jakie dane podać do zapytania.

Błąd 8: nieaktualne daty i dane

Cena, dostępność, dokumenty, schema i Merchant Center pokazują różne informacje.

Błąd 9: brak logów botów AI

Firma nie wie, kto pobiera treści, co widzi i co jest blokowane.

Błąd 10: traktowanie llms.txt jako gwarancji

Google mówi, że dla Google Search i jego funkcji generatywnych nie trzeba tworzyć nowych plików maszynowo czytelnych ani specjalnego markup. Pliki typu llms.txt mogą być eksperymentalnie przydatne dla niektórych narzędzi lub agentów, ale nie są war/ AI Mode. citeturn684749view2turn112366search11

35. Audyt techniczny GEO/AEO/AIO/A2A — lista kontrolna

Crawling i indeksacja

Czy ważne strony są indeksowalne?
Czy robots.txt nie blokuje przypadkiem stron przychodowych?
Czy Googlebot ma dostęp do CSS/JS?
Czy AI search boty są obsługiwane świadomie?
Czy Search Console nie pokazuje problemów indeksacji?
Czy CDN/WAF nie blokuje crawlerów?

Struktura URL i canonical

Czy każda encja ma URL kanoniczny?
Czy filtry nie tworzą śmieciowych indeksowalnych stron?
Czy canonicale są spójne?
Czy PDF-y nie konkurują z HTML?
Czy sitemap zawiera tylko kanoniczne URL-e?

Treść technicznie dostępna

Czy główna treść jest w HTML?
Czy tabele są tabelami, a nie obrazami?
Czy FAQ jest widoczne?
Czy parametry produktu są tekstowe?
Czy dokumenty mają strony opisowe?
Czy obrazy i wideo mają kontekst tekstowy?

Dane strukturalne

Czy Organization jest wdrożone?
Czy Product/Offer/Service są poprawne?
Czy FAQPage odpowiada widocznemu FAQ?
Czy BreadcrumbList jest poprawny?
Czy daty są aktualne?
Czy @id jest spójne?
Czy sameAs prowadzi do właściwych profili?

AEO i odpowiedzi

Czy strona ma krótką odpowiedź na początku?
Czy nagłówki odpowiadają na pytania użytkowników?
Czy są sekcje „dla kogo”, „kiedy nie”, „co sprawdzić”?
Czy są porównania?
Czy są ograniczenia?
Czy są dowody?

GEO/AIO

Czy strona może być cytowana?
Czy marka jest połączona z kategorią?
Czy są zewnętrzne potwierdzenia marki?
Czy AI poprawnie rozumie firmę?
Czy strona pojawia się w promptach testowych?
Czy konkurencja jest cytowana zamiast nas?

A2A

Czy jest strona danych do wyceny?
Czy jest formularz RFQ?
Czy są feedy lub API?
Czy dokumentacja jest czytelna?
Czy agent może zebrać parametry?
Czy są zabezpieczenia i limity?

36. Plan wdrożenia na 30 dni

Dni 1–3: crawl i indeksacja

Sprawdź robots.txt, sitemap, canonicale, noindex, Search Console, statusy HTTP, przekierowania i blokady CDN/WAF.

Dni 4–6: renderowanie i HTML

Sprawdź, czy główna treść, linki, schema, parametry i FAQ są dostępne w HTML lub SSR/SSG.

Dni 7–9: schema i encje

Wdroż lub popraw Organization, Product, Service, BreadcrumbList, FAQPage, Article, Person i @id.

Dni 10–12: sitemap i świeżość

Utwórz osobne sitemapy dla produktów, artykułów, dokumentów i wideo. Popraw lastmod, daty aktualizacji i wersje dokumentów.

Dni 13–15: dokumenty i PDF

Dla najważniejszych PDF-ów stwórz strony HTML opisujące dokumenty i połącz je z produktami/usługami.

Dni 16–18: answer-first i tabele

Na stronach przychodowych dodaj krótką odpowiedź, sekcje Q&A, porównania, tabele, checklisty i ograniczenia.

Dni 19–21: linkowanie grafowe

Połącz problem → rozwiązanie → produkt → dokument → case study → RFQ.

Dni 22–24: boty AI i logi

Ustal politykę dla GPTBot, OAI-SearchBot, PerplexityBot, Applebot, ClaudeBot, CCBot i innych. Sprawdź logi i blokady.

Dni 25–26: RFQ i agent-ready

Stwórz stronę „Dane do wyceny” lub „Dla agentów AI”. Dodaj formularz, listę wymaganych danych i kontakt.

Dni 27–28: feedy i API

Dla produktów lub usług przygotuj feed danych, dokumentację, eksport CSV/JSON/XML albo prostą specyfikację OpenAPI.

Dni 29–30: test AI visibility

Przetestuj prompty w Google AI Mode / AI Overviews, ChatGPT, Perplexity, Gemini i Copilot. Zapisz błędy i zaplanuj poprawki.

37. Minimalny standard techniczny strony źródłowej 2026+

Każda ważna strona powinna mieć:

indeksowalny URL,
poprawny canonical,
miejsce w sitemapie,
widoczny H1,
krótką odpowiedź na początku,
logiczne H2/H3,
treść w HTML,
tabele danych,
FAQ,
linki do powiązanych stron,
linki do dokumentów,
datę aktualizacji,
autora lub odpowiedzialność firmy,
Organization/Product/Service schema tam, gdzie pasuje,
BreadcrumbList,
obrazy z alt i podpisem,
CTA,
dane do kontaktu lub RFQ,
brak blokad snippetów na kluczowych fragmentach,
szybkie ładowanie,
poprawny mobile UX.

38. Najważniejsze wnioski na 03.07.2026

Po pierwsze, klasyczne SEO techniczne pozostaje fundamentem. Google wprost mówi, że dla AI Overviews i AI Mode nie ma specjalnych dodatkowych wymagań, a strony muszą spełniać podstawowe warunki Search: indeksowalnośppetów i zgodność z zasadami. citeturn684749view2

Po drugie, query fan-out zmienia architekturę. Jedno pytanie użytkownika może zostać rozbite na wiele podzapytań, więc trzeba budować huby, strony decanie grafowe. citeturn684749view2turn684749view3

Po trzecie, robots.txt stał się polityką biznesową. Nie chodzi już tylko o crawl budget. Trzeba rozdzielić search, AI search, training, user-triggered browsing i boty niezgodne z zasadami. OpenAI, Perplexity i Apple publikują własne informacje o crawlerach, więc zarządziteturn684749view0turn684749view1turn684749view9

Po czwarte, schema jest ważne, ale nie magiczne. Dane strukturalne pomagają w rozumieniu treści i encji, ale muszą odpowiadać widocznej treści i być częścią większego systemu: HTML, linkowaotwierdzeń. citeturn226335search1turn684749view4

Po piąte, A2A jest kierunkiem, nie prostą check-listą rankingową. Firmy powinny zacząć od danych do wyceny, feedów, dokumentacji, API i bezpieczeństwa, a doph agentowych. citeturn684749view7turn684749view8

39. Podsumowanie

SEO techniczne w czasach GEO / AEO / AIO / A2A to już nie tylko „czy robot może wejść na stronę?”. To pytanie:

czy robot może wejść,
czy system AI może zrozumieć,
czy answer engine może zacytować,
czy agent może zebrać dane,
czy użytkownik może podjąć decyzję,
czy firma może otrzymać lepsze zapytanie lub sprzedaż.

Najlepsza strategia na 2026+ to nie pogoń za sztuczkami, ale zbudowanie strony jako źródła prawdy:

czysty HTML,
jasna architektura,
poprawne canonicale,
aktualne sitemap,
świadome robots.txt,
semantyczne nagłówki,
dane strukturalne,
produkty i usługi opisane jak encje,
dokumenty w HTML,
feedy i dane do RFQ,
szybka infrastruktura,
monitoring botów,
testy AI visibility,
bezpieczeństwo agentów.

W klasycznym SEO wygrywała strona, którą Google mógł zaindeksować i ocenić. W nowym SEO wygrywa strona, którą Google, AI i agent mogą zrozumieć, zaufać jej, porównać ją z alternatywami i użyć jako źródło działania.

Propozycja SEO / Yoast

Tytuł SEO:
SEO techniczne w czasach GEO, AEO, AIO i A2A — przewodnik 2026

Slug:
seo-techniczne-geo-aeo-aio-a2a-2026

Meta description:
Aktualny przewodnik 2026: techniczne SEO pod AI Search, Google AI Overviews, answer engines, schema, crawlery AI, feedy, API i agentów A2A.

Fraza kluczowa:
SEO techniczne 2026

Frazy pomocnicze:
GEO, AEO, AIO, A2A, AI Search, Google AI Overviews, AI Mode, schema.org, robots.txt AI, crawlery AI, agent-ready website, techniczne SEO pod AI

Proponowany lead:
SEO techniczne w 2026 roku to nie tylko indeksacja przez Googlebota. To przygotowanie strony jako źródła wiedzy, danych i działań dla Google AI, ChatGPT, Perlexity, answer engines oraz agentów zakupowych.