Masz stronę internetową od ponad 2 lat? 9 rzeczy, które warto sprawdzić w 2026 roku

Dwa lata to w życiu strony internetowej sporo czasu. Zwykle nie widać tego od razu, bo strona nadal się otwiera, formularze na ogół działają, a CMS pozwala dodawać kolejne podstrony. Problemy narastają tam, gdzie trudniej je zauważyć: w indeksacji, szybkości, zabezpieczeniach, analityce, dostępności i widoczności w wyszukiwarkach z AI.

W tym artykule pokazuję, co warto sprawdzić, jeśli Twoja strona ma już ponad 2 lata i od dawna nie przeszła przeglądu technicznego. Nie chodzi o to, żeby od razu budować nową stronę. Często wystarczy audyt, lista priorytetów i kilka trafnie wybranych poprawek.

W tym artykule:

• 1. SEO techniczne i indeksacja
• 2. Treści, intencje wyszukiwania i stare podstrony
• 3. GEO/AEO, czyli widoczność w wynikach z AI
• 4. Core Web Vitals i rzeczywista szybkość strony
• 5. Skrypty, consent mode i analityka
• 6. Aktualizacje bezpieczeństwa CMS-a i frameworka
• 7. Dostępność cyfrowa
• 8. Formularze, konwersje i integracje
• 9. Monitoring, kopie zapasowe i plan reakcji
• Co zrobić po audycie?

1. SEO techniczne i indeksacja

Pierwszy obszar to podstawy SEO, które po dwóch latach potrafią się niepostrzeżenie rozregulować. Ktoś zmienił strukturę menu, ktoś usunął starą sekcję, ktoś dodał nowe filtry na listach produktów lub artykułów, a ktoś inny przekierował landing page kampanii bez sprawdzenia konsekwencji. Po kilku takich zmianach Google widzi inną stronę niż zespół marketingu.

Google niezmiennie podkreśla znaczenie podstaw: strona musi być dostępna dla robotów wyszukiwarki, możliwa do zaindeksowania i zrozumiała. Warto więc zacząć od Google Search Console, przeskanowania serwisu crawlerem i listy najważniejszych adresów URL.

Sprawdź przede wszystkim:

• czy ważne strony są zaindeksowane,
• czy w indeksie nie pojawiły się niepotrzebne strony,
• czy adresy kanoniczne (canonical) wskazują właściwe strony,
• czy robots.txt i meta robots nie blokują ważnych podstron,
• czy mapa witryny (sitemap.xml) jest aktualna,
• czy przekierowania 301 nie tworzą łańcuchów,
• czy tytuły, meta opisy i nagłówki H1 nie są masowo zduplikowane,
• czy ważne podstrony nie są ukryte zbyt głęboko w strukturze serwisu i czy prowadzą do nich linki wewnętrzne.

Najczęstszy błąd po dwóch latach: zespół porównuje tylko ruch organiczny z miesiąca na miesiąc. To za mało. Trzeba sprawdzić, czy strona nadal jest uporządkowana technicznie, bo spadki często wynikają z wielu drobnych zaniedbań, a nie z jednej spektakularnej awarii.

Jeśli Twoja strona działa na Drupalu, warto również przeczytać artykuł 10 funkcji SEO, które powinien mieć nowoczesny system CMS na przykładzie Drupala.

2. Treści, intencje wyszukiwania i stare podstrony

Drugi obszar to treści. Po dwóch latach część artykułów, landing page’y i opisów usług może być nadal poprawna, ale nie odpowiadać już na aktualne pytania klientów. Widać to szczególnie w sektorze B2B oraz w takich branżach jak IT, finanse, edukacja, medycyna i e-commerce.

Zmieniają się produkty, oferta, konkurenci, słownictwo klientów i same wyniki wyszukiwania. Artykuł, który w 2024 roku przyciągał dużo ruchu, w 2026 roku może przegrywać z konkurencją, bo nie odpowiada na nowe warianty zapytań albo nie uwzględnia tego, jak klienci dziś podejmują decyzje.

W audycie treści warto sprawdzić:

• strony z dużym spadkiem kliknięć lub CTR,
• strony z dużą liczbą wyświetleń, ale niską liczbą kliknięć,
• stare wpisy blogowe, które nadal zajmują wysokie pozycje w wynikach wyszukiwania, ale zawierają nieaktualne CTA,
• kanibalizację tematów, czyli kilka podstron odpowiadających na tę samą intencję wyszukiwania,
• brakujące linki wewnętrzne do usług i case studies,
• strony bez autora, daty aktualizacji lub rzeczywistych przykładów,
• treści, które brzmią jak neutralny opis kategorii, a nie odpowiedź eksperta.

Nie każdy stary tekst trzeba przepisywać. Czasem wystarczy dopisać aktualny kontekst, dodać sekcję FAQ, podmienić CTA, usunąć niedziałające linki i dodać odnośnik do nowszego materiału. Decyzję trzeba jednak podjąć świadomie: aktualizujemy, łączymy, zostawiamy albo usuwamy.

3. GEO/AEO, czyli widoczność w wynikach z AI

Jeśli Twoja strona powstała ponad 2 lata temu, prawdopodobnie nikt nie projektował jej z myślą o AI Overviews, AI Mode, Perplexity czy ChatGPT search. W 2026 roku to już nie jest ciekawostka. To osobny kanał, w którym klienci poznają marki, usługi i poradniki.

Google w swoich wytycznych mówi wprost: w wynikach generatywnych nadal liczą się podstawy SEO. Strona musi być zaindeksowana, treść powinna być unikalna, konkretna i przydatna, a ważne informacje muszą być dostępne w formie tekstu. Google nie wymaga specjalnego pliku, takiego jak llms.txt, ani dodatkowych danych strukturalnych, żeby strona pojawiła się w AI Overviews lub AI Mode.

Nie znaczy to, że nic się nie zmieniło. Zmieniło się to, jak użytkownicy trafiają do treści i jak je oceniają. W wyszukiwarkach z AI częściej pojawiają się strony, które jasno odpowiadają na pytania, pokazują doświadczenie, mają uporządkowane sekcje i pozwalają systemom AI ustalić, kto jest autorem, czego dotyczy treść i dlaczego można jej ufać.

W audycie GEO/AEO sprawdź:

• czy kluczowe strony odpowiadają na konkretne pytania klientów,
• czy tekst zawiera definicje, porównania, kryteria wyboru i przykłady,
• czy autorstwo i doświadczenie firmy są widoczne,
• czy dane strukturalne są zgodne z treścią widoczną na stronie,
• czy obrazy i wideo uzupełniają tekst, a nie tylko zdobią układ strony,
• czy firma jest opisana spójnie na stronie, w case studies, profilach i zewnętrznych wzmiankach,
• jak zmieniają się wyświetlenia, kliknięcia i CTR w raporcie Skuteczność w Search Console – Google uwzględnia w nim również ruch z AI Overviews i AI Mode, ale nie udostępnia dla nich osobnego raportu.

W dyskusjach na Reddicie opinie o GEO są mocno podzielone. Jedni widzą spadki kliknięć z AI Overviews, inni twierdzą, że „GEO” to po prostu dobrze zrobione SEO z lepszą strukturą treści. Moja praktyczna rekomendacja jest prosta: nie szukaj trików obliczonych wyłącznie na AI. Przygotuj treść, którą da się cytować, zrozumieć i zweryfikować.

Co dokładnie sprawdzamy na stronach opartych na Drupalu, opisujemy w artykule Poza SEO: co sprawdzamy w audycie Drupal AI-readability.

4. Core Web Vitals i rzeczywista szybkość strony

Strona może działać szybko w dniu wdrożenia, a po dwóch latach być wyraźnie wolniejsza. Wystarczy kilka kampanii, nowe piksele reklamowe, widżet czatu, osadzone zewnętrzne narzędzie, duże zdjęcia wgrane przez redaktora i dodatkowa wtyczka do formularzy. Nie ma jednej dużej awarii. Strona zwalnia stopniowo.

W 2026 roku warto monitorować trzy wskaźniki Core Web Vitals:

• LCP, czyli czas wyświetlenia głównej treści – cel: maksymalnie 2,5 sekundy,
• INP, czyli czas reakcji strony na działanie użytkownika – cel: maksymalnie 200 ms,
• CLS, czyli stabilność układu strony – cel: maksymalnie 0,1.

Ważne: wynik PageSpeed Insights dla jednego adresu URL nie wystarczy. Trzeba sprawdzić różne typy podstron: stronę główną, listę produktów lub artykułów, artykuł, landing page, formularz, stronę logowania, koszyk albo panel klienta. Problem często tkwi w szablonie, a nie w pojedynczym adresie URL.

Typowe przyczyny problemów:

• niezoptymalizowane zdjęcie w sekcji hero,
• za dużo JavaScriptu na pierwszym ekranie,
• pliki CSS i JS blokujące renderowanie strony,
• skrypty zewnętrznych dostawców (third-party) ładowane bez kontroli,
• czcionki internetowe powodujące przesunięcia tekstu podczas ładowania strony,
• reklamy lub banery zmieniające układ strony,
• komponenty frontendowe, które blokują główny wątek przeglądarki.

Jeśli strona działa na Drupalu, warto sprawdzić cache, agregację plików CSS i JS, leniwe ładowanie obrazów (lazy loading), obsługę formatów WebP i AVIF, CDN oraz to, czy niestandardowy motyw (theme) nie dodaje zbyt wiele kodu na każdej podstronie. Więcej praktycznych wskazówek znajdziesz w artykule Szybki CMS: jak poprawić jego wydajność i przyspieszyć stronę?. Audyt wydajności warto połączyć ze wsparciem i utrzymaniem Drupala, żeby rekomendowane poprawki nie skończyły się na raporcie.

5. Skrypty, consent mode i analityka

Po dwóch latach analityka bywa jednym z najbardziej zaniedbanych elementów strony. GA4 wdrożono w pośpiechu, definicje konwersji przestały pasować po przebudowie formularzy, a baner cookies skonfigurowano raz i nikt do niego nie wrócił. W efekcie zespół podejmuje decyzje na podstawie danych, którym nie powinien ufać.

W 2026 roku audyt powinien objąć nie tylko GA4, ale też consent mode, Google Tag Manager, zdarzenia, kampanie płatne i to, czy tagi uruchamiają się dopiero po wyrażeniu zgody przez użytkownika. Google opisuje consent mode jako mechanizm, który dostosowuje zbieranie danych na potrzeby reklam i analityki do zgód wyrażonych przez użytkownika. Źle wdrożony consent mode może jednocześnie powodować utratę danych i ryzyko naruszenia przepisów.

Sprawdź:

• czy zdarzenia GA4 odpowiadają obecnym formularzom i CTA,
• czy Google Ads nie zlicza jako konwersji kliknięć, które nie prowadzą do faktycznej akcji,
• czy GTM nie ładuje nieużywanych tagów,
• czy consent mode v2 jest wdrożony poprawnie,
• czy skrypty reklamowe nie pogarszają INP i LCP,
• czy raporty pokazują dane potrzebne do decyzji, a nie tylko ładne wykresy,
• czy informacja o źródle leada poprawnie trafia do CRM.

W tym obszarze marketing i zespół developerski muszą pracować razem. Marketing wie, co mierzyć. Developerzy wiedzą, czy konkretne wdrożenie ma sens i czy nie spowalnia strony.

6. Aktualizacje bezpieczeństwa CMS-a i frameworka

Jeśli strona działa na CMS-ie albo frameworku open source, po dwóch latach trzeba sprawdzić stan aktualizacji. Nie „kiedyś zrobimy aktualizację”, tylko konkretnie: wersja rdzenia, moduły, wtyczki, pakiety Composera i npm, PHP, baza danych, serwer, konfiguracja cache, panel administracyjny i integracje.

OWASP Top 10 w wersji 2025 nadal pokazuje, że w aplikacjach webowych powtarzają się te same kategorie zagrożeń. Społeczność Drupala publikuje komunikaty dotyczące bezpieczeństwa rdzenia i modułów społecznościowych. CISA prowadzi katalog znanych podatności, które są aktywnie wykorzystywane w atakach. To nie są teoretyczne listy dla audytorów. Regularne śledzenie tych źródeł to element bieżącego utrzymania strony.

W audycie bezpieczeństwa sprawdź:

• czy CMS lub framework jest w wersji objętej wsparciem,
• czy moduły i wtyczki mają aktywnych opiekunów,
• czy w projekcie nie ma porzuconych bibliotek,
• czy Composer i npm nie zgłaszają znanych podatności,
• czy panel administracyjny jest chroniony uwierzytelnianiem wieloskładnikowym (MFA), a role użytkowników mają ograniczone uprawnienia,
• czy formularze są zabezpieczone przed spamem i nadużyciami,
• czy kopie zapasowe da się rzeczywiście odtworzyć,
• czy wiadomo, kto reaguje na krytyczne komunikaty bezpieczeństwa i w jakim czasie.

W przypadku Drupala warto dodatkowo sprawdzić, czy strona nie pozostała na starszej wersji pomocniczej (minor), która nie otrzymuje już poprawek bezpieczeństwa, oraz czy kod niestandardowy nie blokuje aktualizacji. Dlaczego na komunikaty bezpieczeństwa trzeba dziś reagować szybciej niż kiedyś, wyjaśniamy w artykule Aktualizacje bezpieczeństwa Drupala w erze AI. Jeśli planujesz większą aktualizację, zobacz też, jak wygląda aktualizacja do Drupala 11.

7. Dostępność cyfrowa

Dostępność nie jest już tematem „na kiedy będzie czas”. Europejski akt o dostępności (European Accessibility Act) obowiązuje od 28 czerwca 2025 roku i dotyczy wybranych produktów i usług, m.in. e-commerce, bankowości, transportu, usług telekomunikacyjnych i e-booków. Najnowszą wersją wytycznych jest WCAG 2.2 i warto ją stosować nawet wtedy, gdy organizacja nie ma jeszcze formalnego obowiązku prawnego.

Po dwóch latach dostępność często pogarsza się w wyniku codziennej edycji treści. Pojawiają się brakujące teksty alternatywne, nieprawidłowa hierarchia nagłówków, tekst umieszczony na grafikach, banery, których nie da się obsłużyć klawiaturą, nowe kolory wprowadzone bez sprawdzenia kontrastu i formularze bez czytelnych komunikatów błędów.

Sprawdź:

• kontrast tekstu i przycisków,
• obsługę strony klawiaturą,
• widoczne wyróżnienie aktywnego elementu (focus),
• teksty alternatywne obrazów,
• strukturę nagłówków,
• etykiety pól formularzy,
• komunikaty błędów,
• dostępność menu, okien modalnych i komponentów dynamicznych,
• dostępność plików PDF publikowanych na stronie.

To nie jest tylko wymóg prawny. Z dostępnej strony zwykle łatwiej korzystać każdemu, szczególnie na telefonie, przy słabym świetle, w pośpiechu albo przy wolniejszym połączeniu. Jak podejść do dostępności w Drupalu, opisujemy w artykule Dostępność w Drupalu. Jak stworzyć stronę internetową zgodną ze standardami?.

8. Formularze, konwersje i integracje

Wiele firm ocenia stronę na podstawie ruchu, a nie tego, co użytkownicy na niej robią. Po dwóch latach warto przejść najważniejsze ścieżki użytkownika tak, jak zrobiłby to klient: wejście z Google, lektura podstrony usługi, kliknięcie CTA, wypełnienie formularza, otrzymanie potwierdzenia, zapis w CRM i powiadomienie działu sprzedaży.

Brzmi banalnie. W praktyce właśnie tu wychodzą na jaw braki: formularz działa, ale lead trafia do CRM bez źródła. CTA prowadzi do starej strony. Automatyczne powiadomienie trafia do osoby, która już nie pracuje w firmie. Komunikat po wysłaniu formularza nie informuje, co stanie się dalej. Polska wersja strony ma inne pola niż angielska.

W audycie sprawdź:

• czy wszystkie formularze wysyłają dane tam, gdzie powinny,
• czy komunikaty walidacji pól są zrozumiałe,
• czy zgody marketingowe są aktualne,
• czy potwierdzenia e-mailowe nadal mają poprawną treść,
• czy dla każdego leada zapisywane są źródło, kampania i strona wejścia,
• czy CTA pasują do aktualnej oferty,
• czy wersje językowe prowadzą użytkownika w ten sam sposób,
• czy najważniejsze landing page’e jasno wskazują kolejny krok.

Jeśli strona działa na Drupalu, te problemy często da się naprawić bez przebudowy całego serwisu, wprowadzając poprawki w module Webform, integracjach z CRM, widokach (Views), blokach CTA i strukturze treści. Przy większych zmianach warto zaplanować dalszy rozwój strony na Drupalu, żeby usunąć przyczynę problemu, a nie tylko jego objawy.

9. Monitoring, kopie zapasowe i plan reakcji

Ostatni obszar jest najmniej widowiskowy, ale jego zaniedbanie często kosztuje najwięcej. Po dwóch latach strona powinna mieć jasny plan: co monitorujemy, kto dostaje alerty, kto reaguje, gdzie są kopie zapasowe, ile trwa ich odtworzenie i co uznajemy za incydent.

Minimum do sprawdzenia:

• monitoring dostępności (uptime) strony i kluczowych ścieżek użytkownika,
• monitoring ważności certyfikatów SSL i domen,
• alerty o błędach 5xx,
• logi aplikacji i serwera,
• kopie zapasowe bazy danych i plików,
• test odtworzenia kopii zapasowej,
• lista osób do eskalacji,
• procedura reakcji na krytyczne podatności,
• osobne środowisko testowe (staging).

Bez tego zespół reaguje dopiero wtedy, gdy problem zauważy klient albo zarząd. Taki sposób działania jest ryzykowny. Stronę firmową, szczególnie w B2B, finansach, edukacji, medycynie czy e-commerce, trzeba traktować jak system biznesowy, a nie zbiór podstron. Jeśli nie masz jeszcze takiego planu, zacznij od monitoringu serwerów i aplikacji.

Co zrobić po audycie?

Dobry audyt nie kończy się na raporcie w PDF. Jego efektem powinna być decyzja: co robimy teraz, co planujemy na później, a czego nie robimy wcale. Po dwóch latach zwykle nie brakuje tematów. Brakuje priorytetów.

Proponuję prosty podział:

• krytyczne: bezpieczeństwo, awarie formularzy, błędy indeksacji ważnych stron,
• szybkie poprawki: metadane, CTA, przekierowania, ciężkie obrazy, nieużywane tagi,
• prace planowane: refaktoryzacja motywu, poprawki dostępności, porządkowanie treści,
• decyzje strategiczne: aktualizacja CMS-a, zmiana architektury, przeprojektowanie wybranych ścieżek użytkownika.

Wynik audytu rzadko oznacza, że trzeba budować stronę od nowa. Częściej pokazuje, które elementy warto zmieniać etapami. Takie podejście opisujemy w artykule Nie przebudowuj, ewoluuj: etapowy framework modernizacji CMS.

Jeśli Twoja strona działa na Drupalu i od dłuższego czasu nikt jej nie audytował, warto zacząć od przeglądu technicznego: SEO, wydajności, bezpieczeństwa, dostępności, analityki i procesu publikowania treści. W Droptica pomagamy zespołom utrzymywać i rozwijać strony na Drupalu, od bieżącego wsparcia po większe zmiany w architekturze. Jeśli chcesz najpierw sprawdzić stan systemu i ustalić priorytety, zobacz nasz audyt kodu Drupala.

Jeśli zamiast zgadywać wolisz otrzymać konkretną listę ryzyk i rekomendowanych działań, skontaktuj się z nami. Sprawdzimy, co naprawdę wymaga poprawy, a co może poczekać.