WordPress itself is uncritical — the data-protection issues almost always come via themes, plugins and embedded content.
In practice, most WordPress privacy problems sit in three sources: the theme, which often loads Google Fonts or icon kits from external CDNs; marketing and analytics plugins that write their tracking code straight into the <head> without querying a consent status; and the block editor, which resolves YouTube, Maps and Twitter embeds immediately on page view. Each of these sources can be defused individually.
A consent plugin alone is not enough if it does not actually block the scripts. Many banner plugins only show the notice while the tracking plugins load in parallel. What works is solutions that either hold back the known trackers via a script blocker or hook deep into the respective plugins (e.g. via their consent APIs).
WordPress core functions are themselves uncritical, with one exception: the emoji scripts load s.w.org by default and can — depending on the setup — trigger an external connection. Gravatars in the comment area also transmit a hash of the email address to automattic.com. Both can be switched off with a few lines in functions.php or a small plugin.
Common sources: themes that load Google Fonts from Google; analytics or marketing plugins without consent logic; embedded YouTube/Maps blocks; emojis and Gravatars from external servers. For all non-necessary access, § 25 (1) TDDDG applies.
The free scan checks the delivered HTML and shows which services are embedded, whether a cookie banner is detected and whether privacy-policy and legal-notice links are present — with context for each finding. It is not a substitute for legal advice.
This text is general information to the best of our knowledge, not legal advice. For an individual case, consult a law firm specialising in IT law.