Ostatnio zrobiłem 20 przebiegów Lighthouse na tych samych ustawieniach mobilnych dla swojej strony i trzech stron z wyników na frazy „website audit”. Jedna z nich ładowała największy element treści (LCP) w medianie po 13,3 s i mimo to dostała 71 punktów, a moja przy 5,8 s tylko 69. Same punkty stawiają więc wyżej stronę wolniejszą o 7,4 sekundy (pełny pomiar w benchmarku strony z konkurencją).
Dlatego raport audytu strony dla klienta mówi najpierw, co naprawić, na jakiej podstawie, kto to zrobi i jak sprawdzicie efekt. Poniżej składam go w dziesięciu krokach, a szablony i fikcyjny przykład raportu pobierzesz od razu.
Co zawiera raport audytu strony dla klienta
Raport audytu strony dla klienta to dokument, który zamienia wyniki badania w decyzje i zadania z warunkami odbioru. Na górze stoją decyzje do akceptacji, a pod nimi zakres, ustalenia z dowodami, plan prac i retest.
Czyta go kilka osób: właściciel firmy chce decyzji, prowadzący projekt ustala zakres, a developer potrzebuje opisu do odtworzenia. Ja bym napisał jeden dokument w warstwach, z podsumowaniem dla decydenta na górze i szczegółami technicznymi niżej. Taki podział zaleca OWASP w części o raportowaniu testów bezpieczeństwa, a ja przenoszę go na cały raport strony jako własną adaptację, bez statusu obowiązkowego standardu.
| Część raportu | Co ma otrzymać odbiorca | Co powinno się tam znaleźć |
|---|---|---|
| Podsumowanie | Decyzję o dalszych pracach | Cel, najważniejsze ustalenia, ograniczenia i proponowany następny krok |
| Zakres i metoda | Informację, jak daleko sięgają wnioski | URL-e, szablony, stany, urządzenia, źródła, daty i wyłączenia |
| Ustalenia | Materiał do wykonania pracy | Problem, dowód, znaczenie, rekomendacja, właściciel i warunek odbioru |
| Plan i retest | Sposób organizacji oraz zamknięcia prac | Kolejność, zależności, wycena, odpowiedzialność, wynik ponownego testu |
Każde ważne ustalenie odpowiada na pięć pytań:
Eksporty z narzędzi idą do załączników, a treść główna odsyła do konkretnego dowodu. Szablon raportu z oceny dostępności W3C ma podobne części (zakres, proces oceny i wyniki z rekomendacjami), więc ten sam układ działa też jako sprawozdanie z wykonania audytu.
Krok 1: Ustal zakres badania, zanim napiszesz wnioski
Zakres badania to lista adresów, stanów strony i zadań użytkownika, które naprawdę sprawdziłeś. Zapis „audyt całej strony” nie mówi, czy sprawdzono koszyk, formularz po błędnym wysłaniu, wersję mobilną albo panel po zalogowaniu. Zapisz zadania, które sprawdzałeś (znalezienie produktu, zamówienie, zapytanie, odzyskanie konta), i dopisz do nich język, stan zgód oraz rolę użytkownika.
Odróżnij inwentaryzację, plan badania i badanie wykonane, bo sitemapa mówi tylko, co da się zbadać. Które adresy faktycznie otwarto i oceniono po wyrenderowaniu, zapisujesz osobno, a timeout, blokadę dostępu albo błąd narzędzia jako nieudaną próbę.
Przy większym serwisie opisz dobór próbki, bo strona główna i dwie podstrony nie reprezentują wszystkich formularzy, szablonów stron i stanów. WCAG-EM 2.0 uwzględnia dobór próbki i pełne procesy, a zarazem przestrzega przed deklarowaniem zgodności całego serwisu wyłącznie na podstawie podzbioru.
Liczbę URL-i, ocenionych szablonów i sprawdzonych scenariuszy zapisz osobno, bo jeden adres potrafi mieć kilka ważnych stanów. Gdy nie znasz liczby wszystkich stron, napisz „pełna liczebność nieustalona”, bo procent pokrycia z nieznanego mianownika to liczba wzięta z powietrza. Wyłączenia stawiaj obok podsumowania, bo bez dostępu do płatności nie potwierdzisz całego zakupu i zdanie „sklep działa poprawnie” odpada.
Krok 2: Opisz dowód tak, żeby inna osoba mogła go sprawdzić
Dowód to zapis, z którego ktoś inny odtworzy tę samą obserwację. Ustalenie dostaje stały identyfikator, np. A11Y-01, osobny od identyfikatorów wystąpień, bo ten sam link w nagłówku może siedzieć na wielu stronach i wymagać jednej zmiany w komponencie.
Do dowodu dopisz:
- URL albo ścieżkę dojścia;
- datę ze strefą czasową;
- środowisko i stan strony;
- nazwę i wersję narzędzia;
- opis wyniku, a przy pomiarach jednostkę i ustawienia.
Zrzut ekranu pomaga znaleźć element, ale obserwację wyjaśnia dopiero drzewo dostępności, nagłówki HTTP albo zapis żądań. Te pola chronią przed liczbą, która tylko wygląda na pomiar, i sam się na tym złapałem, kiedy GA4 pokazało mi ostatnio 70 sesji na cometweb.io w 28 dni. Dopiero raport źródło/medium rozbił je na kanały i pokazał, skąd się wzięły:
Realnie to ok. 1 sesja dziennie, a bez źródła, okresu czy podziału na kanały „70 sesji” trafiłoby do raportu jako fakt.
Trzymaj osobno obserwację, wniosek o skutku, hipotezę przyczyny i rekomendację. Brak programowo dostępnej nazwy linku to obserwacja, a to, że osobie z czytnikiem ekranu trudno rozpoznać cel linku, to już uzasadniony opis bariery według W3C przy kryterium 4.1.2 Name, Role, Value. Spadek sprzedaży o określony procent wymaga innych danych niż test dostępności.
Focus i aktywację klawiaturą sprawdzasz osobno od nazwy, a zanim wpiszesz wszędzie aria-label, oceń, czy wystarczy właściwy tekst linku.
Przyczynę niesprawdzoną w kodzie oznacz jako hipotezę, bo podobne ostrzeżenia potrafią pochodzić z różnych komponentów. Grupuj je dopiero przy potwierdzonej wspólnej przyczynie albo z dopiskiem, że to robocze założenie.
Krok 3: Wypełnij kartę ustalenia na przykładzie
Karta ustalenia to jedna tabela, w której problem i dowód stoją obok właściciela i warunku odbioru. Pustą pobierzesz jako kartę ustalenia.
Scenariusz fikcyjny. Adresy, identyfikatory dowodów i liczby w karcie są ilustracyjne. Sklepu nikt nie badał, a przykład służy wyłącznie nauce i nie pokazuje pomiarów klienta ani wyników CometWeb.
| Pole | Przykładowy zapis |
|---|---|
| Identyfikator i tytuł | A11Y-01: link „Moje konto” bez programowo dostępnej nazwy |
| Zakres obserwacji | W scenariuszu: 6 z 6 sprawdzonych stron zawierających ten wariant nagłówka; pozostałe stany nieustalone |
| Dowód | Fikcyjny zapis E-01: rola link, pusta nazwa, cel /konto; lokalizacja elementu w nagłówku |
| Znaczenie | Osobie korzystającej z czytnika ekranu może być trudno rozpoznać cel linku; nie oszacowano wpływu na przychód |
| Przyczyna | Hipoteza: wspólny komponent zawiera samą ikonę; wymaga potwierdzenia w kodzie |
| Rekomendacja | Nadać opisową nazwę, preferując właściwy tekst, i sprawdzić wszystkie warianty komponentu |
| Priorytet i właściciel | Propozycja P2; developer odpowiedzialny za komponent; akceptacja zakresu po stronie prowadzącego projekt |
| Warunek odbioru | W każdym sprawdzanym wariancie drzewo dostępności pokazuje właściwą nazwę i rolę; oddzielnie sprawdzono focus, Enter oraz docelową stronę |
| Status | Do potwierdzenia zakresu i realizacji; ponownego testu jeszcze nie wykonano |
Z taką kartą zlecisz pracę bez tłumaczenia jej na spotkaniu.
Krok 4: Rozdziel priorytet, dotkliwość i pewność
Dotkliwość opisuje skutek problemu, priorytet ustala kolejność pracy w projekcie, a pewność mówi, co naprawdę potwierdzono.
Niepewny sygnał o poważnym zagrożeniu wymaga szybkiej weryfikacji, nawet gdy brakuje jeszcze dowodów. Podział priorytetów poniżej to moja własna propozycja organizacji pracy.
| Priorytet | Kiedy go rozważyć | Decyzja dla zespołu |
|---|---|---|
| P1: pilnie | Potwierdzona blokada ważnego procesu lub istotne zagrożenie wymagające reakcji | Wskazać osobę odpowiedzialną, ograniczyć skutek i ustalić pilny test |
| P2: najbliższy zakres prac | Istotna, potwierdzona bariera, której usunięcie ma wyraźne znaczenie | Zaplanować poprawkę i odbiór |
| P3: planowo | Usprawnienie z mniejszym wpływem albo zależne od wcześniejszych prac | Ustalić termin po rozwiązaniu zależności |
| P4: obserwacja | Sygnał bez wystarczającego kontekstu lub niski priorytet poprawy | Wskazać, jakie dane i kiedy rozstrzygną dalsze działanie |
Błąd we wspólnym szablonie nie trafia do P1 automatycznie, bo drobny problem na wielu stronach bywa mniej pilny niż niedziałający formularz na jednej ważnej podstronie. Mała liczba użytkowników nie usuwa za to bariery dostępności.
Łatwość poprawki porządkuje pracę wewnątrz priorytetu. Do zadań dopisz zależności: poprawa linków może czekać na decyzję o docelowych URL-ach, a zmiana cache na zasady obsługi koszyka.
Krok 5: Pokaż wyniki z różnych obszarów bez mieszania znaczeń
Każdy obszar audytu ma własne źródło danych i granice wniosków, więc raport pokazuje je osobno.
Wydajność: źródło pomiaru przed liczbą
Przy Core Web Vitals (LCP, INP, CLS) napisz, skąd jest wynik: z laboratorium, z CrUX czy z monitoringu prawdziwych wizyt. Dopisz URL albo origin, typ urządzenia i okres. Według web.dev i dokumentacji CrUX API dane originu (np. https://www.example.com) obejmują wszystkie jego strony razem, a pojedynczej podstrony nie mierzą.
Lighthouse daje różne wyniki w kolejnych przebiegach, jak opisuje Chrome for Developers przy punktacji wydajności, więc pokaż liczbę prób, warunki testu i pełny rozrzut. Na cometweb.io/website-audit LCP w Lighthouse (mobile) różnił się o 886 ms między najszybszym a najwolniejszym z pięciu przebiegów jednego ranka we wrześniu 2026.
Interakcje mierzy INP, a TBT z testu ładowania to tylko sygnał pomocniczy. Dobre wartości to LCP do 2,5 s, INP do 200 ms i CLS do 0,1 na 75. percentylu wizyt według web.dev. Mediana kilku prób laboratoryjnych to wciąż laboratorium, a terenowe p75 liczy się z prawdziwych wizyt.
Wyniku zbiorczego nie składaj sam: średnia punktów za wydajność, SEO czy bezpieczeństwo jako „procent zdrowia strony” miesza różne skale. Wynik narzędzia podawaj z nazwą i metodologią, a także zakresem i brakami danych. Pamiętaj też, że blokada procesu bywa pilna mimo wysokiej oceny.
SEO: konfiguracja strony osobno, decyzja Google osobno
Canonical w HTML, adres wybrany przez Google i widoczność w wynikach to trzy różne obserwacje. Kod strony i dane z URL Inspection dokumentuj osobno, z datą ostatniego crawlowania. Test aktualnego URL-a w Search Console opisuje wersję na żywo, a wersję w indeksie pokazuje osobny widok.
Przekierowania nie dopisuj do każdej rekomendacji canonical, bo pasuje do wycofywanego adresu, a przy potrzebnych wariantach strony decyzja bywa inna. Według Google Search Central o adresach kanonicznych spójne sygnały pomagają wskazać preferowany URL, ale wybór należy do Google.
Poprawne dane strukturalne dają szansę na wynik rozszerzony, a decyzję znów podejmuje Google (wytyczne danych strukturalnych). Nazwij narzędzie, badany typ i zakres kontroli, bo „schema: zaliczone” klientowi nic nie mówi.
Dostępność: automat sprawdza część kryteriów
Przy ustaleniu dostępności podaj kryterium, wersję WCAG, sposób oceny i badany stan. Automat uzupełnij testami manualnymi i technologiami asystującymi, bo według W3C WAI żadne narzędzie nie sprawdza wszystkich aspektów dostępności. Wypisz, co sprawdzono i co pominięto, bo inaczej czytelnik weźmie brak ostrzeżenia za zgodność.
Nie przedstawiaj punktów skanera jako „96% zgodności z WCAG”. W3C w opisie zgodności określa wymagania zgodności, a takiego procentu WCAG nie przewiduje. Obowiązki prawne to osobna ocena.
Granicę między automatem a testem manualnym opisuję w tekście o audycie dostępności WCAG i EAA.
Bezpieczeństwo i CO₂e: wniosek tak szeroki jak badanie
Kontrola nagłówków HTTP i TLS to tylko wycinek testu bezpieczeństwa, więc zapisz, czy analizowano uwierzytelnianie i role, a także API i dane po zalogowaniu. Zdanie „strona jest bezpieczna” po ograniczonym badaniu to obietnica bez pokrycia, a OWASP podkreśla, że ocena dotyczy konkretnego momentu i może pominąć część zagrożeń.
Przy CO₂e nazwij wynik estymacją i podaj model, wersję, dane wejściowe oraz granice obliczenia (Green Web Foundation, modele CO2.js). Model oparty na transferze szacuje emisję z przesłanych danych, a energii zużytej przez konkretny telefon nie odczytuje, dlatego stan przed i po porównujesz tą samą metodą.
Krok 6: Napisz podsumowanie dla klienta
Podsumowanie łączy cel, najważniejszy problem, propozycję działania oraz granicę wiedzy i zwykle mieści się w krótkiej pierwszej części dokumentu.
Przykład fikcyjny:
Celem badania było przygotowanie sklepu do poprawek przed kolejną kampanią. W scenariuszu oceniono sześć publicznych stron i wybrane interakcje. Zalecamy najpierw nadać nazwę linkowi „Moje konto” we wspólnym nagłówku oraz wyjaśnić sprzeczne wskazania canonical na dwóch stronach. Zespół musi zatwierdzić docelowe URL-e przed wdrożeniem zmian SEO. Nie badano rzeczywistej płatności, panelu po zalogowaniu ani całego zakresu WCAG. Brak danych terenowych INP nie pozwala ocenić reakcji serwisu u rzeczywistych użytkowników. Klient powinien zatwierdzić zakres pierwszych dwóch zadań, wskazać osobę odpowiedzialną za decyzje SEO i ustalić dostęp do retestu.
Prognozy wzrostu sprzedaży bez podstaw nie dopisuj. Według Google o page experience dobry wynik Core Web Vitals nie zapewnia wysokich pozycji, a poprawa techniczna, trend ruchu i wynik biznesowy wymagają własnych dowodów.
Krok 7: Przypisz właścicieli, koszt i zależności w planie wdrożenia
Plan wdrożenia daje każdemu zadaniu jednego właściciela realizacji i osobę, która zaakceptuje wynik: developer naprawia komponent, QA robi retest. Klient decyduje o zakresie, a poprawność kodu ocenia zespół techniczny, więc proponowaną odpowiedzialność oznacz w planie jako propozycję.
Sugerowany właściciel mieści się zwykle w jednej z pięciu ról, które ostatecznie przypisuje organizacja:
| Rola | Za co odpowiada |
|---|---|
| Developer | kod, routing, nagłówki, wydajność i komponenty |
| SEO | indeksowanie, canonical, sitemap, dane strukturalne i linkowanie |
| Content | tytuły, definicje, brakujące odpowiedzi i jakość tekstu |
| Design i dostępność | kontrast, focus, kolejność interakcji i komunikaty |
| Właściciel lub marketing | priorytet biznesowy, akceptacja zakresu i termin |
Rozpoznanie przyczyny, implementację, testy, wdrożenie i kontrolę produkcji wyceniasz osobno, z założeniami. Bez dostępu do kodu albo dostawcy zewnętrznego wpisz „do wyceny po rozpoznaniu” w miejsce pozornie precyzyjnej liczby godzin.
Uzgodnij, co obejmuje zlecenie: badanie, konsultację czy wdrożenie, i ile rund retestu. Rekomendacja to propozycja, a zamówienie jej wykonania to osobna decyzja, tak samo jak warianty i prace dodatkowe.
Stan z raportu trzymaj osobno od bieżącej listy zadań. Zachowaj wersję, którą dostał klient, odsyłaj z zadań do identyfikatorów ustaleń, a obrazek „po” dokładaj obok wcześniejszego dowodu.
Krok 8: Zrób retest i zamknij ustalenie
Retest to powtórzenie tego samego scenariusza po poprawce, sprawdzone względem warunku odbioru zapisanego przed pracą. Warunek wskazuje stan, oczekiwany rezultat i metodę, a „wynik ma być zielony” jest na to za ogólny.
Po wdrożeniu odtwórz scenariusz, sprawdź ważne warianty i regresje, a stan pracy i rezultat weryfikacji zapisuj osobno, np. w karcie retestu i odbioru.
Przy akceptacji ryzyka zapisz, kto i dlaczego zdecydował oraz termin ponownego przeglądu, a wynik techniczny zostaje wtedy negatywny.
Przy wydajności porównuj te same konfiguracje i statystykę, a zmianę narzędzi, zakresu badania albo urządzenia zaznacz jako ograniczenie porównania. Różnica między mobile i desktop wynika z samych urządzeń, więc opisz ją osobno od efektu wdrożenia.
Według dokumentacji CrUX API dane aktualizują się codziennie w ruchomym oknie 28 dni, więc po poprawce mieszają wizyty sprzed zmiany i po niej. Zapisz okres zbierania danych zamiast obiecywać datę poprawy wyniku.
Ręcznie to sporo pilnowania, dlatego w CometWeb Insight wyniki wszystkich modułów trafiają do raportu z priorytetami i kolejki zadań ze statusem. Ponowny skan w tym samym zakresie i tą samą metodologią pokazuje, co poprawiono, co zostało otwarte i co doszło. Status „zrobione” to sygnał do ponownego skanu, bo przy znaleziskach wykrywanych automatycznie dowodem jest dopiero ten skan, a ręczne warunki odbioru sprawdzasz jak wyżej.
Krok 9: Przekaż raport czytelnie i bezpiecznie
Czytelny raport ma opisowe nagłówki, zrozumiałe odnośniki i statusy zapisane tekstem, czytelne także bez koloru. Każdy zrzut dostaje opis bariery albo obserwacji (W3C WAI o pisaniu dostępnych treści).
HTML ułatwia nawigację, a PDF służy jako zamrożona wersja przekazania. W obu sprawdzasz strukturę, kolejność odczytu, działanie linków i czytelność na małym ekranie, a zbiór obrazków zapisany jako PDF odpada.
Poufny raport wysyłaj kanałem z kontrolą dostępu, z ustalonymi odbiorcami, okresem przechowywania i możliwością cofnięcia udostępnienia. Z publicznego przykładu usuń dane osób, tokeny, identyfikatory sesji, adresy administracyjne i szczegóły nienaprawionej podatności, a oryginalny dowód przechowuj osobno.
noindex nie zabezpiecza poufnego raportu, bo każdy, kto zna link, i tak otworzy stronę. Google odróżnia wyłączenie z indeksu od ochrony przed nieuprawnionym dostępem, a trudny do odgadnięcia adres nic nie mówi o tożsamości odbiorcy.
Krok 10: Zakończ spotkanie z klientem decyzjami
Spotkanie ma skończyć się listą decyzji, więc podsumowanie i główne ustalenia wyślij wcześniej. Na spotkaniu pokaż najważniejszy dowód, wyjaśnij zasięg skutku i zaproponuj kolejność, a pełną listę ostrzeżeń zostaw w załączniku.
Na koniec zapisz przyjęte zadania z właścicielami i warunkami odbioru, odłożone prace i otwarte pytania. Jeśli klient potrzebuje więcej czasu na decyzję, ustal, jakiej informacji mu brakuje. Po spotkaniu zaktualizuj rejestr i powiąż go z wersją raportu.
Trzy wnioski o raporcie audytu
- Wniosek sięga tak daleko jak badanie. Eksport bez priorytetów albo raport bez zakresu i daty zostawia klientowi tłumaczenie danych, a automatyczny audyt dostępności certyfikacją nie jest.
- Obserwację i przyczynę trzymaj osobno od rekomendacji. Wystąpienia o potwierdzonej wspólnej przyczynie łącz w jedno zadanie.
- Pracę zamyka retest. Bez właściciela i warunku odbioru przy każdym ustaleniu zespół nie wie, kiedy skończył.
Listę problemów wygeneruje każde narzędzie, a resztę zacznij od szablonu raportu, w którym puste pola mają status „nieustalone”, więc czytelnik od razu widzi brak wyniku.
Przykładowy raport Insight pokazuje prezentację wyników, a metodologia CometWeb wyjaśnia źródła, braki danych i priorytety. Jeśli chcesz mieć wszystkie obszary jakości strony w jednym widoku, z kolejką zadań i ponownym skanem, załóż konto w CometWeb Insight.
Najczęstsze pytania o raport audytu strony
Czy eksport z Lighthouse wystarczy jako raport dla klienta?
Może być załącznikiem lub wynikiem wąsko określonego zlecenia. Przy szerszym audycie trzeba dodać interpretację, zakres, dowody, priorytety i plan weryfikacji. Wynik jednego uruchomienia opisuje jego warunki, nie wszystkie wizyty.
Ile stron powinien mieć raport audytu?
Tyle, ile potrzeba do przekazania ustaleń i podjęcia decyzji. Krótki dokument może być kompletny dla małego zakresu. Duży serwis zwykle wymaga rozbudowanych załączników. Liczba stron nie zastępuje opisu próbki, stanów i metod.
Czy każde ostrzeżenie powinno być osobnym zadaniem?
Nie. Łącz wystąpienia o potwierdzonej wspólnej przyczynie, pozostawiając listę lokalizacji i wariantów do retestu. Odmienna przyczyna, właściciel albo sposób weryfikacji może uzasadniać osobne zadanie.
Jak opisać brak danych?
Podaj, czego brakuje, dlaczego i jaki wniosek jest przez to niedostępny. Rozróżniaj „nie badano”, „test nie powiódł się”, „brak danych terenowych” i „nie dotyczy”. Wartość zero jest wynikiem, a nie zamiennikiem niewykonanego pomiaru.
Kiedy można napisać, że problem naprawiono?
Kiedy istnieje wynik retestu potwierdzający wcześniej ustalony warunek we wskazanym zakresie. Sam commit, wdrożenie, zamknięcie zadania lub decyzja o akceptacji ryzyka nie wystarczają. W pozostałych przypadkach wpisz aktualny stan pracy i brakującą weryfikację.
Czy wynik punktowy wystarczy jako podsumowanie?
Wynik może zorientować czytelnika, ale nie powinien prowadzić decyzji. Liczba bez zakresu, źródła i daty ukrywa braki w pokryciu i miesza pomiar z rekomendacją. Prowadź raport ustaleniami i dowodami, a wynik traktuj jako etykietę, nie jako treść.
Źródła i zakres poradnika
To poradnik przygotowania raportu technicznego. Przykłady są fikcyjne; nie stanowią audytu, testu penetracyjnego, deklaracji zgodności ani wyceny konkretnej strony. Podział priorytetów, wzory kart i zasady odbioru są propozycją organizacji pracy, bez statusu nowego standardu technicznego.
- OWASP WSTG: Reporting. Odbiorcy, zakres, ograniczenia, wersjonowanie i ochrona raportu.
- W3C: WCAG Evaluation Methodology 2.0. Próba, pełne procesy, zakres twierdzeń i ograniczenia punktacji. Group Note z 23.07.2026.
- Chrome for Developers: CrUX API. Zakres URL/origin, urządzenie, dzienna aktualizacja i ruchome okno 28 dni.
- web.dev: Web Vitals. LCP, INP i CLS, 75. percentyl oraz progi dobrego wyniku.
- Google Search Central: Canonical URLs. Canonical i przekierowanie to różne decyzje; sygnały nie są gwarancją wyboru Google.
- Google Search Console: URL Inspection tool. Wersja w indeksie, test aktualnego URL-a i ograniczenia interpretacji.
- W3C WAI: Selecting Web Accessibility Evaluation Tools. Narzędzia wspierają ocenę, ale nie sprawdzają wszystkich aspektów dostępności.
- W3C WAI: Understanding SC 4.1.2: Name, Role, Value. Programowo dostępna nazwa i rola; przykład linku.
- W3C WAI: Understanding Conformance. Warunki zgodności WCAG, pełne strony i procesy.
- Green Web Foundation: CO2.js models. Estymacje emisji, wersja modelu i granice systemu.
- Google Search Central: Control what you share. Noindex nie blokuje bezpośredniego dostępu; ochrona treści poufnych.
- Google Search Central: Understanding page experience. Dobry wynik CWV nie gwarantuje wysokich pozycji.