Jak przygotować stronę na agentów AI. Poradnik | emedia

Jak przygotować stronę na agentów AI i dostać 3/3 w Lighthouse

Grzegorz Wysocki
CEO | Strategiczne doradztwo marketingowe dla 100+ firm
W skrócie
  • Od Chrome 150 Lighthouse ma nową kategorię Przeglądanie agentowe. Ocenia, czy agent AI da radę obsłużyć Twoją stronę, i pokazuje wynik jako ułamek, na przykład 2/3.
  • Do wyniku liczą się trzy kontrole: drzewo dostępności, stabilność układuplik llms.txt. Trzy kontrole WebMCP są na razie tylko informacyjne.
  • Jedna brakująca nazwa przycisku albo ikony zeruje całą kontrolę dostępności. Na emedia.pl robiły to cztery ikony social media w stopce.
  • Pozycjonowanie AI to trzy osobne prace: być cytowanym przez modele, odpowiadać na pytania i dać się obsłużyć agentowi. Ten wpis dotyczy tej trzeciej.

Klient nie zawsze wchodzi na Twoją stronę osobiście. Coraz częściej wysyła tam agenta: Gemini wbudowane w Chrome, przeglądarkę Comet od Perplexity albo agenta w ChatGPT, który dostał polecenie „znajdź firmę, sprawdź cennik i wyślij zapytanie”. Agent nie patrzy na stronę jak człowiek. Czyta jej strukturę i klika po współrzędnych. Jeśli przycisk nie ma nazwy albo strona przesuwa się w trakcie ładowania, agent kończy zadanie bez kontaktu z Tobą.

Google zaczął to mierzyć. W Chrome 150 pojawiła się w Lighthouse kategoria Przeglądanie agentowe (Agentic Browsing), a jej wynik widać też w PageSpeed Insights. Zmierzyliśmy nią pięć stron emedia.pl 4 września 2026: żadna nie dostała 3/3, a powód na wszystkich pięciu był ten sam. Poniżej tłumaczymy, co ta kategoria sprawdza, jak ją uruchomić w 5 minut i co zlecić programiście, żeby dojść do kompletu.


Kto ogląda Twoją stronę zamiast klienta?

Przez lata strona miała dwóch czytelników: człowieka i robota wyszukiwarki. W 2026 roku doszedł trzeci, agent AI działający w przeglądarce. Google wbudował go w Chrome jako funkcję Auto Browse w Gemini, Perplexity wydało przeglądarkę Comet, która sama przegląda sklepy, porównuje oferty i wypełnia formularze, a Microsoft dołożył Copilota do Edge. OpenAI poszło inną drogą: własną przeglądarkę Atlas wycofało po dziewięciu miesiącach, 9 sierpnia 2026, a jej funkcje agentowe przeniosło do aplikacji ChatGPT i wtyczki do Chrome.

Wspólny mianownik tych narzędzi: użytkownik pisze cel, agent wykonuje kliknięcia. „Zarezerwuj stolik na piątek”, „znajdź hydraulika w Lublinie i wyślij zapytanie”, „porównaj trzy oferty i wrzuć najtańszą do koszyka”. Agent otwiera strony, czyta je i klika. Nie ogląda ich jednak jak człowiek. Zamiast obrazu dostaje drzewo dostępności, czyli listę elementów z ich rolami i nazwami, tę samą, z której korzystają czytniki ekranu dla osób niewidomych. Dokumentacja Chrome ujmuje to jednym zdaniem: agenci sprawdzają drzewo ułatwień dostępu, aby zidentyfikować elementy interaktywne.

Konsekwencja dla Twojej strony jest prosta. Przycisk „Wyślij zapytanie”, który dla człowieka jest pomarańczowym prostokątem, dla agenta jest wpisem „button” z nazwą. Jeśli nazwy brakuje, bo przycisk to sama ikona bez tekstu, agent widzi element bez znaczenia i go pomija. Jeśli strona w trakcie ładowania przesuwa się o kilkadziesiąt pikseli, agent, który zdążył zrobić zrzut ekranu, klika tam, gdzie przycisk był przed chwilą. Oba problemy dotykają też ludzi, ale człowiek poprawia się po chwili, a agent kończy zadanie z błędem.


Pozycjonowanie AI to trzy różne rzeczy

Pod hasłem „pozycjonowanie AI” kryją się trzy prace, które wymagają innych działań i innych ludzi. Mieszanie ich prowadzi do sytuacji, w której firma płaci za „widoczność w AI”, a dostaje przepisane opisy produktów.

  • Być cytowanym (GEO, generative engine optimization). Model językowy odpowiada użytkownikowi i powołuje się na Twoją stronę jako źródło. Decydują o tym treść, jej struktura, źródła i to, czy roboty AI mają wstęp. O tym pisaliśmy w tekście GEO: jak być widocznym w chatbotach AI.
  • Odpowiadać na pytania (AEO, answer engine optimization). Strona ma sekcje, które wprost odpowiadają na pytania klientów: cennik, warunki, terminy, FAQ z danymi strukturalnymi. To praca redakcyjna i SEO.
  • Dać się obsłużyć agentowi (gotowość na przeglądanie agentowe). Agent ma znaleźć przycisk, wypełnić formularz i nie trafić w baner. To praca techniczna na kodzie strony i właśnie ją Google mierzy w Lighthouse.

Pierwsze dwie prace przyprowadzają agenta na stronę. Trzecia decyduje, czy agent na niej cokolwiek załatwi. Firma, którą modele cytują, a której formularz nie ma etykiet, jest jak sklep z dobrą reklamą i zamkniętymi drzwiami. Reszta tego wpisu dotyczy drzwi.

Chcesz wiedzieć, czy agent AI załatwi sprawę na Twojej stronie?

Zmierzymy Twoją stronę w Lighthouse, wskażemy elementy, które oblewają kontrole, i podamy czas naprawy w godzinach.


Przeglądanie agentowe w Lighthouse: skąd wynik 3/3?

Lighthouse to narzędzie Google wbudowane w Chrome (zakładka DevTools) i w serwis PageSpeed Insights. Do tej pory oceniało cztery obszary: wydajność, ułatwienia dostępu, sprawdzone metody i SEO. W wersji 13.3 z maja 2026 doszła piąta kategoria, Agentic Browsing, po polsku Przeglądanie agentowe. W Chrome 150, którego nowości Google opisał 30 czerwca 2026, pojawiła się w panelu DevTools jako osobne pole wyboru, domyślnie wyłączone. Google opisuje ją jako eksperymentalną i wymaga Chrome 150 lub nowszego.

Ta kategoria liczy wynik inaczej niż pozostałe. Zamiast średniej ważonej od 0 do 100 pokazuje ułamek: ile kontroli gotowości strona zaliczyła. Kontrole są zero-jedynkowe. Strona albo przechodzi daną kontrolę w całości, albo nie. W Lighthouse 13.4 do wyniku wchodzą trzy kontrole, dlatego komplet to 3/3, a strona z jednym problemem dostaje 2/3.

Co sprawdza: czy każdy element interaktywny ma nazwę i poprawną rolę. Lighthouse przepuszcza stronę przez 33 reguły dostępności: nazwy linków, przycisków i pól, poprawność atrybutów ARIA, tytuł dokumentu, kolejność fokusu.

Jak oblewa: jedno naruszenie na stronie daje 0. Cztery ikony social media bez nazwy w stopce wystarczą, żeby oblała każda podstrona serwisu.

Kto naprawia: programista albo osoba edytująca WordPressa. Zwykle chodzi o alt obrazka, tekst przycisku lub etykietę pola. Czas: od 10 minut do kilku godzin.

Co sprawdza: wskaźnik CLS (Cumulative Layout Shift), czyli o ile treść przesuwa się w trakcie ładowania. Próg zaliczenia to 0,1, ten sam co w kategorii wydajności.

Jak oblewa: obrazy bez zapisanych wymiarów, pasek cookies wciskający treść w dół, fonty podmieniane po załadowaniu, bloki wstawiane skryptem. Agent klika w miejsce, gdzie przycisk był przed przesunięciem.

Kto naprawia: programista. Czas zależy od liczby przyczyn, zwykle 2 do 8 godzin na szablon.

Co sprawdza: czy pod adresem twojadomena.pl/llms.txt leży plik tekstowy z nagłówkiem i przynajmniej jednym linkiem. To streszczenie strony dla modeli językowych, pisane w Markdownie.

Jak oblewa: tylko wtedy, gdy serwer odpowie błędem albo plik nie ma nagłówka i linków. Brak pliku (błąd 404) nie obniża wyniku, bo plik jest opcjonalny.

Kto naprawia: osoba od treści. Wtyczka Yoast SEO generuje ten plik sama, ale wersja ręczna z opisami usług i cen jest lepsza. Czas: 1 do 2 godzin.

Poza tymi trzema kontrolami raport pokazuje trzy pozycje związane z WebMCP: zarejestrowane narzędzia, formularze bez deklaracji i poprawność schematu. Mają wagę zero. Nie podnoszą i nie obniżają wyniku, bo WebMCP jest na etapie testów w Chrome i większość stron go nie ma. Piszemy o tym osobno w ostatnim wpisie serii.


Trzy kontrole i WebMCP w skrócie

Każdej kontroli poświęcamy osobny wpis z listą napraw dla WordPressa. Tu zbieramy to, co trzeba wiedzieć, żeby rozmawiać z programistą bez tłumacza.

Drzewo dostępności: nazwa dla każdego przycisku

Przeglądarka buduje z kodu strony listę elementów z rolami (link, przycisk, pole, nagłówek) i nazwami. Nazwa bierze się z tekstu elementu, z atrybutu alt obrazka albo z etykiety pola. Kurs Learn Accessibility od Google podaje trzy zapisy, które dają tę samą nazwę „Czerwone skórzane buty”: link z tekstem, link z obrazkiem z alt i pole z etykietą. Ikona bez tekstu i bez alt nie daje nic. Lighthouse dla agentów sprawdza 33 reguły, w tym: przyciski i linki mają nazwę, pola mają etykiety, obrazy w linkach mają alt, atrybuty ARIA są poprawne, strona ma tytuł, nikt nie ustawił tabindex większego niż zero. Więcej w drugim wpisie serii: Jak poprawić dostępność strony w WordPressie, żeby agent AI znalazł każdy przycisk.

Stabilność układu: strona ma stać w miejscu

CLS mierzy, jak bardzo widoczna treść przesunęła się bez działania użytkownika. Dobry wynik to 0,1 lub mniej. Google podaje pięć typowych przyczyn: obrazy bez atrybutów width i height, reklamy i osadzenia bez zarezerwowanego miejsca, treść wstawiana skryptem nad tym, co już widać, fonty podmieniane po załadowaniu i animacje zmieniające pozycję elementów. Dla agenta każde przesunięcie to ryzyko kliknięcia obok. Więcej w czwartym wpisie: Jak poprawić Cumulative Layout Shift (CLS) w WordPressie.

llms.txt: broszura dla modeli językowych

Plik llms.txt to propozycja Jeremy’ego Howarda z września 2024. Leży w katalogu głównym domeny, jest pisany w Markdownie i zawiera nagłówek z nazwą firmy, krótki opis oraz sekcje z linkami do najważniejszych stron, każdy z jednozdaniową notatką. Lighthouse sprawdza tylko, czy plik się otwiera i ma nagłówek oraz link. Yoast SEO generuje go automatycznie w WordPressie, ale plik napisany ręcznie, z usługami, cenami i adresami biur, robi więcej. Więcej w trzecim wpisie: Jak zrobić plik llms.txt na stronie firmowej.

WebMCP: strona sama mówi, co można zrobić

WebMCP to proponowany standard, w którym strona deklaruje agentowi swoje „narzędzia”: ten formularz wysyła zapytanie ofertowe, tamten rezerwuje termin. Zamiast zgadywać po wyglądzie pól, agent dostaje nazwę narzędzia, opis i opis każdego parametru. Chrome testuje to w programie origin trial od wersji 149 (czerwiec 2026). Lighthouse pokazuje trzy kontrole WebMCP, ale nie liczy ich do wyniku. Więcej w piątym wpisie: Co to jest WebMCP i co przygotować na stronie, zanim agenci AI zaczną z niej korzystać.


Jak zmierzyć swoją stronę w 5 minut?

Najprostsza droga prowadzi przez Chrome, bez instalowania czegokolwiek:

  1. Otwórz swoją stronę w Chrome 150 lub nowszym (wersję sprawdzisz w menu, pozycja „Chrome to informacje”).
  2. Naciśnij F12 albo Ctrl+Shift+I, żeby otworzyć narzędzia deweloperskie, i przejdź do zakładki Lighthouse.
  3. W liście kategorii zaznacz Agentic browsing. Domyślnie jest odznaczona. Możesz odznaczyć pozostałe, wtedy pomiar trwa kilkanaście sekund.
  4. Wybierz urządzenie (telefon lub komputer) i kliknij „Analyze page load”.
  5. Odczytaj ułamek u góry raportu i rozwiń każdą kontrolę z czerwonym znacznikiem. Przy kontroli drzewa dostępności raport pokazuje konkretny element strony, który oblał, z fragmentem jego kodu.

Drugi sposób to PageSpeed Insights pod adresem pagespeed.web.dev. Wpisujesz adres, czekasz kilkadziesiąt sekund i dostajesz ten sam raport, wygodny do wysłania linkiem programiście. Trzeci sposób, dla osób technicznych, to Lighthouse z linii poleceń z parametrem kategorii agentic-browsing. Tak zmierzyliśmy pięć stron emedia.pl naraz i zapisaliśmy raporty do porównania po naprawie.

Dwa zastrzeżenia. Wynik potrafi się różnić między pomiarami: Google tłumaczy to czasem rejestracji narzędzi WebMCP, wariancją drzewa dostępności i przesunięciami układu wywołanymi przez reklamy albo obrazy bez wymiarów. Mierz więc trzy razy i patrz na powtarzalny problem, nie na pojedynczy wynik. Po drugie, mierz kilka typów stron, nie tylko główną. Na emedia.pl strona główna miała 2/3, a strona usługi 1/3, bo doszedł tam przycisk wyszukiwarki bez nazwy i przesunięcie układu.


Ile ma emedia.pl i dlaczego nie 3/3?

Zmierzyliśmy pięć stron własnego serwisu 4 września 2026, Lighthouse w wersji 13.4.1, w trybie telefonu. Wyniki przed naprawą:

Strona Wynik Co oblało
strona główna2/3cztery ikony social media w stopce bez nazwy
strona kontaktu2/3stopka oraz ukryte pole antyspamowe formularza bez etykiety
kategoria usług Web development2/3stopka oraz przycisk wyszukiwarki bez tekstu
strona usługi Google Ads1/3stopka, przycisk wyszukiwarki, przesunięcie układu 0,145
wpis na blogu1/3stopka, nagłówek z niedozwoloną rolą ARIA, przesunięcie układu od 0,24 do 0,50 w kolejnych pomiarach

Plik llms.txt zaliczyły wszystkie strony, bo prowadzimy go ręcznie. Kontrolę drzewa dostępności oblały wszystkie, i to z jednego powodu: w stopce serwisu są cztery obrazki-linki do Facebooka, Instagrama, LinkedIna i TikToka z pustym atrybutem alt. Dla człowieka to rozpoznawalne ikony, dla agenta cztery linki bez nazwy. Naprawa polega na wpisaniu alt „Facebook emedia”, „Instagram emedia” i tak dalej w jednym bloku stopki. Dziesięć minut pracy, a każda podstrona zyskuje jedną kontrolę.

Reszta to typowe usterki WordPressa. Przycisk wyszukiwarki w motywie ma samą ikonę lupy i wymaga atrybutu aria-label. Formularz kontaktowy ma ukryte pole antyspamowe (honeypot), które dla Lighthouse jest polem bez etykiety. Wpisy na blogu dostają nagłówkom rolę ARIA z jednego ze skryptów, a ich obrazy nie mają zapisanych wymiarów, stąd przesunięcie układu od 0,24 do 0,50 w kolejnych pomiarach, przy progu 0,1. Pełna kategoria ułatwień dostępu daje stronie głównej 92 na 100, ale do kontroli dla agentów nie wchodzi ani kontrast kolorów, ani brak elementu main, więc te 92 nic nie mówią o wyniku 2/3.

Grzegorz Wysocki, CEO emedia

Grzegorz Wysocki
CEO emedia

Komentarz autora: pierwszy odruch, gdy zobaczyłem nową kategorię w PageSpeed, był taki, że chcę mieć 3/3 na własnej stronie, zanim zaczniemy to proponować klientom. Pomiar sprowadził temat na ziemię: pięć stron, jeden powód na wszystkich, cztery ikony w stopce bez nazwy. To nie jest projekt na kwartał, tylko lista drobnych zaniedbań, które dotąd nikomu nie przeszkadzały, bo człowiek widzi ikonę Facebooka bez podpisu. Agent jej nie widzi. Tę serię piszemy po to, żeby marketingowiec umiał sam zrobić pomiar, przeczytać raport i zlecić naprawę bez tłumaczenia, co to jest drzewo dostępności.


Co z tego ma marketingowiec?

Trzy rzeczy, w tej kolejności.

Po pierwsze, jeden wynik zamiast dyskusji. Do tej pory „czy nasza strona jest gotowa na AI” było pytaniem bez miary. Teraz jest ułamek, który każdy może sprawdzić w przeglądarce w 5 minut i który po naprawie zmienia się z 2/3 na 3/3. To dobry argument w rozmowie z zarządem i z agencją.

Po drugie, ta sama praca zamyka dwa tematy naraz. Kontrola drzewa dostępności dla agentów to podzbiór reguł dostępności dla ludzi. Od 28 czerwca 2025 obowiązuje w Polsce ustawa z 26 kwietnia 2024 o zapewnianiu spełniania wymagań dostępności niektórych produktów i usług, wdrażająca Europejski Akt o Dostępności. Obejmuje między innymi usługi handlu elektronicznego, także bezpłatne, a zwalnia mikroprzedsiębiorców i działalność kierowaną wyłącznie do firm. Sama ustawa nie wpisuje WCAG jako wymogu, ale to do tych wytycznych odsyłają akty wykonawcze i praktyka audytów. Naprawiając nazwy przycisków i etykiety pól dla agentów, robisz część tej pracy. Światowa Organizacja Zdrowia szacuje, że 1,3 miliarda osób żyje z niepełnosprawnością, a to ci sami użytkownicy, którzy korzystają z drzewa dostępności przez czytniki ekranu.

Po trzecie, gotowa lista do zlecenia. Zamiast prosić programistę „zrób stronę pod AI”, wysyłasz raport Lighthouse i ten spis:

  • każdy link i przycisk z samą ikoną dostaje nazwę (alt obrazka lub aria-label), w tym ikony social media, lupa wyszukiwarki, strzałki karuzeli, przycisk menu na telefonie;
  • każde pole formularza ma etykietę, także pola ukryte przed człowiekiem, na przykład antyspamowe;
  • obrazy mają zapisane atrybuty width i height, a bloki wstawiane skryptem mają zarezerwowane miejsce;
  • skrypty motywu i wtyczek nie dokładają ról ARIA do nagłówków i zwykłych elementów;
  • plik llms.txt istnieje, ma nagłówek z nazwą firmy, opis i sekcje z linkami do usług, cennika i kontaktu;
  • po naprawie ponowny pomiar trzech typów stron: głównej, usługi i wpisu na blogu.

Automatyczne testy dostępności obejmują według Google około 30 procent kryteriów WCAG, więc 3/3 w Lighthouse nie znaczy, że strona jest dostępna w pełni. Znaczy, że agent AI nie potknie się o najczęstsze przeszkody. Na start to wystarczy.


Jak emedia może w tym pomóc?

Robimy to samo, co opisaliśmy wyżej, tylko na Twojej stronie. Zaczynamy od pomiaru: Lighthouse na kilku typach stron, w trybie telefonu i komputera, z zapisanymi raportami. Z raportów wyciągamy listę elementów, które oblewają kontrole, i przypisujemy do każdego czas naprawy w godzinach. Naprawy w WordPressie, WooCommerce, Shoperze i IdoSell wykonujemy sami w ramach usług Web development. Plik llms.txt piszemy ręcznie, na podstawie oferty i cennika, i wpinamy w istniejący audyt SEO, bo tam sprawdzamy też dostęp robotów AI i dane strukturalne. Po naprawie mierzymy ponownie i oddajemy oba raporty, przed i po.


Podsumowanie

Agent AI w przeglądarce czyta stronę przez drzewo dostępności i klika po współrzędnych, więc potrzebuje nazwanych przycisków i układu, który nie skacze. Google mierzy to od maja 2026 w kategorii Przeglądanie agentowe w Lighthouse, dostępnej w Chrome 150 i w PageSpeed Insights. Wynik to ułamek z trzech kontroli: drzewo dostępności, stabilność układu i plik llms.txt. Jedna brakująca nazwa zeruje kontrolę, dlatego pięć stron emedia.pl dostało 2/3 i 1/3 przez cztery ikony w stopce. Pomiar zajmuje 5 minut, większość napraw to minuty lub pojedyncze godziny, a ta sama praca przybliża stronę do wymagań ustawy o dostępności.


Przeczytaj także


Najczęstsze pytania

Czy wynik przeglądania agentowego wpływa na pozycję w Google?

Google nie ogłosił, że ta kategoria jest czynnikiem rankingowym, i opisuje ją jako eksperymentalną. Mierzy gotowość strony na agentów, nie pozycję w wynikach. Dwie z trzech kontroli, dostępność i stabilność układu, pokrywają się jednak z tym, co Google od lat premiuje u ludzi, więc naprawa nie jest pracą na marne.

Nie widzę kategorii Przeglądanie agentowe w swoim Lighthouse. Dlaczego?

Najczęściej dlatego, że Chrome jest starszy niż wersja 150 albo pole wyboru kategorii jest odznaczone, bo Google wyłączył je domyślnie. Zaktualizuj przeglądarkę i zaznacz kategorię w panelu Lighthouse przed uruchomieniem pomiaru. W PageSpeed Insights kategoria pojawia się bez dodatkowych ustawień.

Moja strona ma 100 punktów za dostępność, a kontrola dla agentów oblewa. Jak to możliwe?

To dwie różne miary. Wynik dostępności to średnia ważona kilkudziesięciu audytów, więc jedna usterka o niskiej wadze prawie go nie obniża. Kontrola dla agentów bierze 33 wybrane reguły i jest zero-jedynkowa: jedno naruszenie na stronie daje zero. Sprawdź w raporcie, który element oblał, zwykle chodzi o link lub przycisk bez nazwy.

Czy muszę mieć plik llms.txt, żeby dostać 3/3?

Brak pliku nie obniża wyniku, bo Google traktuje go jako opcjonalny: kontrola oblewa dopiero wtedy, gdy serwer odpowie błędem albo plik nie ma nagłówka i linków. Sam plik jest jednak tani w przygotowaniu i daje modelom językowym streszczenie oferty w jednym miejscu, więc robimy go w każdym audycie.

Czy WebMCP trzeba wdrażać już teraz?

Nie. WebMCP jest w fazie testów w Chrome i kontrole z nim związane mają w Lighthouse wagę zero. Dziś wystarczy przygotować grunt: każde pole formularza ma atrybut name i etykietę, a formularze działają bez sztuczek w JavaScripcie. Gdy standard wyjdzie z testów, dopisanie atrybutów zajmie godzinę.

Ile kosztuje dojście do 3/3?

Zależy od tego, co oblewa. Na emedia.pl naprawa stopki to 10 minut, przycisk wyszukiwarki i pole antyspamowe po pół godziny, a przesunięcia układu na wpisach 2 do 8 godzin, bo trzeba uzupełnić wymiary obrazów i zmienić sposób wstawiania bloków. Wycenę robimy po pomiarze, per element z raportu.


Jak to powstaje. Tematy, pomiary i ostatnie słowo: Grzegorz Wysocki. Redakcja i porządkowanie źródeł: Claude (Anthropic). Diagram: makieta własna, obraz wygenerowany w GPT Image 2 i sprawdzony ręcznie. Zrzut kategorii agentowej pochodzi z raportu Lighthouse dla emedia.pl z 5 września 2026.

Na czym to stoi. Chrome for Developers, dokumentacja kategorii Agentic Browsing w Lighthouse (ocena, ułatwienia dostępu dla agentów, stabilność układu, llms.txt, WebMCP), stan na 4 września 2026; kod źródłowy Lighthouse 13.4.1 (lista 33 reguł kontroli drzewa dostępności); wpis „What’s new in DevTools, Chrome 150”, 30 czerwca 2026; kurs Learn Accessibility na web.dev; specyfikacja llmstxt.org, Jeremy Howard, 3 września 2024, aktualizacja 10 sierpnia 2026; dokumentacja WebMCP i ogłoszenie origin trial, Chrome 149, 9 czerwca 2026; DebugBear, „Google Lighthouse Has A New Agentic Browsing Category”, 10 maja 2026; PurePC o wycofaniu przeglądarki Atlas, lipiec 2026; Prawo.pl i Infor.pl o ustawie z 26 kwietnia 2024 o zapewnianiu spełniania wymagań dostępności niektórych produktów i usług, w mocy od 28 czerwca 2025. Pomiary emedia.pl: 4 września 2026, Lighthouse 13.4.1, Chrome 151, tryb telefonu. Czego nie wiemy, o tym piszemy wprost: Google nie podał, czy i kiedy kategoria przestanie być eksperymentalna.

Realizacja: artykuł zrealizowany przez człowieka we współpracy z systemami AI. Redakcję i publikację firmuje autor.

Opublikowano 05.09.2026

Więcej na ten temat: agenci AI Lighthouse dostępność Widoczność w AI

0/5 (0 głosy)

Rozwiń z nami swój biznes on-line

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Wymagane pola są oznaczone *


Skontaktuj się z nami i zacznijmy
budowanie Twojego biznesu!

Skorzystaj z bezpłatnej wyceny lub wyślij nam wiadomość