Sam WordPress jest nieproblematyczny — tematy ochrony danych przychodzą prawie zawsze przez motywy, wtyczki i osadzone treści.
W praktyce większość problemów z ochroną danych w WordPressie tkwi w trzech źródłach: motyw, który często ładuje Google Fonts lub zestawy ikon z zewnętrznych CDN; wtyczki marketingowe i analityczne wpisujące swój kod śledzący bezpośrednio w <head> bez odpytania statusu zgody; oraz edytor blokowy, który natychmiast rozwiązuje osadzenia YouTube, Maps i Twittera przy ładowaniu strony. Każde z tych źródeł można rozbroić osobno.
Sama wtyczka zgody nie wystarczy, jeśli faktycznie nie blokuje skryptów. Wiele wtyczek banerowych tylko wyświetla komunikat, podczas gdy wtyczki śledzące ładują się równolegle. Skuteczne są rozwiązania, które wstrzymują znane trackery przez blokadę skryptów albo głęboko integrują się z odpowiednimi wtyczkami (np. przez ich API zgody).
Funkcje rdzenia WordPressa są same w sobie nieszkodliwe, z jednym wyjątkiem: skrypty emoji domyślnie ładują s.w.org i mogą — zależnie od konfiguracji — wywołać połączenie zewnętrzne. Gravatary w obszarze komentarzy przesyłają dodatkowo hash adresu e-mail do automattic.com. Oba można wyłączyć kilkoma liniami w functions.php lub małą wtyczką.
Częste źródła: motywy ładujące Google Fonts od Google; wtyczki analityczne lub marketingowe bez logiki zgody; osadzone bloki YouTube/Maps; emoji i Gravatary z zewnętrznych serwerów. Dla każdego niekoniecznego dostępu obowiązuje § 25 ust. 1 TDDDG.
Bezpłatny skan sprawdza dostarczony HTML i pokazuje, jakie usługi są osadzone, czy wykryto baner cookie oraz czy są linki do prywatności i noty prawnej — z omówieniem dla każdego ustalenia. Nie zastępuje porady prawnej.
Ten tekst to ogólna informacja według najlepszej wiedzy, nie porada prawna. W konkretnej sprawie skonsultuj się z kancelarią specjalizującą się w prawie IT.