WordPress privacy and third-party requests

WordPress privacy and third-party requests are closely connected because a website does not need to set a tracking cookie before information begins leaving the visitor’s browser.

A seemingly simple WordPress page can load resources from:

• font providers;
• analytics platforms;
• advertising networks;
• video platforms;
• social networks;
• map providers;
• CDNs;
• captcha services;
• live-chat systems;
• payment providers;
• Gravatar;
• external APIs.

Each external request creates another connection between the visitor and infrastructure outside the WordPress website itself.

That connection may expose technical information such as:

IP address
request timestamp
browser information
referrer information
requested resource
connection metadata

and depending on the service, request and visitor state, it may also involve:

• cookies;
• local storage;
• account identifiers;
• advertising identifiers;
• analytics identifiers;
• behavioral data;
• embedded-content interactions.

This does not mean every third-party request is automatically unlawful, dangerous or invasive.

It means every external dependency should be understood rather than treated as invisible infrastructure.

This guide explains what third-party requests are, how WordPress sites create them, what information can leave the browser, how fonts, embeds, analytics, CDNs and Gravatar fit into the picture, how to audit a WordPress site’s network activity and how to reduce unnecessary external dependencies without pretending that privacy can be solved by installing one more plugin with a green shield icon.

What is a third-party request?

Suppose your website is:

https://example.com/

The browser loads:

https://example.com/style.css

That is a request to the same site infrastructure.

Now suppose the CSS loads a font from another hostname

https://fonts.example-provider.com/font.woff2

The browser now connects to another service.

That is a third-party request in the practical web-privacy sense

Another example:

example.com
↓
loads page
↓
browser requests
www.youtube.com
fonts.googleapis.com
www.google-analytics.com
connect.facebook.net

The visitor is no longer communicating only with example.com

Their browser is establishing network connections to several organizations.

Third party does not necessarily mean another visible company

A resource might be served from:

cdn.example.com

while the underlying CDN infrastructure belongs to another provider.

Technical ownership and legal roles can differ

A CDN may process requests on behalf of the website owner.

An analytics service may process data under a separate contractual relationship.

An embedded social network may determine significant parts of its own processing.

Do not classify privacy obligations from the hostname alone

Architecture tells you:

where the request goes.

Legal analysis needs to determine:

why it goes there,
what data is processed,
under whose instructions,
for what purpose,
and on what legal basis.

This guide focuses on the technical side

It is not legal advice.

Privacy law varies by jurisdiction, implementation and organizational context.

Why a request can matter even without cookies

One of the most persistent misconceptions is:

No cookies
=
no privacy issue.

That is technically incomplete

For a browser to retrieve a resource from a remote server, the server must receive enough information to respond.

At minimum, network communication involves an IP address

Conceptually:

Visitor browser
IP: 203.0.113.25
↓
requests font
↓
external server receives request
↓
external server sends font

The request may also contain HTTP headers

Depending on browser policy and request type, examples may include:

User-Agent

Referer

Accept

Accept-Language

Sec-Fetch-* headers

Cookie

Not every request contains every header

Modern browsers apply increasingly strict privacy and referrer rules.

But the architectural principle remains:

external resource
=
external connection.

This is why WordPress plugin privacy guidance mentions external images

The official WordPress Plugin Handbook privacy guidance explicitly tells plugin developers to consider whether a plugin loads resources such as:

• third-party JavaScript;
• tracking pixels;
• iframes;
• external images.

An external image can be a network signal

Consider:

<img
    src="https://third-party.example/pixel.gif"
    alt=""
>

The image can be one pixel

It can still generate a request.

That request can reveal that the page was loaded

Depending on implementation, the URL itself might even contain identifiers:

/pixel.gif?visitor=12345

A resource does not need JavaScript to become tracking infrastructure

This is why privacy reviews must inspect network behavior, not merely scan HTML for the word:

cookie

WordPress itself is not the whole website

A stock WordPress installation provides a core platform.

The real site may also include:

WordPress Core
+
theme
+
plugins
+
page builder
+
custom code
+
embedded content
+
external SaaS
+
hosting infrastructure

Any of these layers can generate third-party requests

So asking:

Does WordPress make third-party requests?

is usually less useful than asking:

What third-party requests does
this specific WordPress installation
generate for this specific visitor?

Different users can trigger different requests

An anonymous visitor may load:

• analytics;
• fonts;
• video embeds.

A logged-in administrator may additionally load:

• plugin update checks;
• remote dashboard widgets;
• Gravatar;
• plugin APIs;
• license services.

A checkout visitor may trigger another set

For example:

• payment-provider JavaScript;
• fraud-detection APIs;
• address-autocomplete systems.

Privacy audits need multiple page states

Testing only the homepage while logged out provides an incomplete picture.

Common sources of third-party requests in WordPress

Typical categories include:

Web fonts
Analytics
Advertising
Embeds
Maps
Captcha
CDNs
Avatars
Payment services
Chat widgets
Social widgets
External APIs
Remote media

Google Fonts and other remote font providers

A WordPress theme may contain something like:

<link
    rel="stylesheet"
    href="https://fonts.googleapis.com/..."
>

The browser first contacts the stylesheet provider

Then the returned CSS normally references one or more font files.

Conceptually:

example.com
↓
fonts.googleapis.com
↓
font stylesheet
↓
fonts.gstatic.com
↓
font file

This creates external connections before the visitor reads anything

The requests happen because typography has been configured as a remote dependency.

The font itself may be harmless

But its delivery architecture still matters.

You can remove the remote dependency through self-hosting

Instead of:

Visitor
↓
Google font servers

you can use:

Visitor
↓
example.com
↓
local .woff2 file

See Self-hosting Google Fonts in WordPress.

Self-hosting changes the data path

It does not merely change performance.

The external request disappears because the font is now served from infrastructure controlled by or operating for the site.

Remote vs. self-hosted fonts is therefore both a performance and privacy decision

See also CDN vs. self-hosted assets in WordPress.

Do not assume every CDN is equivalent to a public third-party embed

A CDN serving your site’s static assets may operate under your configuration and contractual control.

A social-media iframe provides a very different processing context.

Both create network requests

But their privacy implications can be very different.

Analytics scripts

Analytics is one of the most obvious sources of third-party requests.

A page may load:

<script
    src="https://analytics-provider.example/script.js"
></script>

The script may then generate additional requests

For example:

page loads
↓
analytics JavaScript downloads
↓
script executes
↓
collects page/event data
↓
sends measurement request

One external script can create many downstream requests

This is an important audit principle.

Do not count only:

<script src="...">

elements.

Inspect runtime network activity

A third-party JavaScript library can dynamically:

• create iframes;
• load additional scripts;
• send API requests;
• store identifiers;
• read existing browser storage.

This makes JavaScript a particularly powerful third-party dependency

You are not merely downloading a file.

You are executing code in the visitor’s browser.

Advertising and tracking pixels

Advertising systems can involve:

• JavaScript;
• pixels;
• iframes;
• cookie synchronization;
• conversion requests;
• audience identifiers.

These should never be treated as generic presentation assets

The business purpose matters.

An image used as a logo and a tracking pixel can both be IMG requests

But their purposes are entirely different.

Privacy analysis must consider purpose

What does this resource do?

Why is it loaded?

What information does it receive?

What happens after it receives it?

Third-party embeds

WordPress makes embedding external media extremely convenient.

You can paste a supported URL such as a YouTube video into the editor and WordPress can convert it into embedded content.

The official WordPress oEmbed documentation explains that WordPress uses oEmbed providers to retrieve the HTML necessary to represent external media.

Embedded content is not copied into WordPress

In a typical iframe-based embed:

WordPress page
↓
contains iframe
↓
visitor browser loads
external provider

The external service becomes part of the visitor’s page load

This matters for privacy and performance.

See Why Third-Party Embeds Slow Down WordPress.

WordPress’s own suggested privacy-policy text warns about embedded content

Core explains that embedded content from external websites can behave similarly to visiting those websites directly.

That is an important mental model

If you embed:

YouTube
Vimeo
social post
external map

you are not merely showing a screenshot.

You are embedding another application’s content environment

Depending on the service, the provider may be able to:

• receive visitor connection data;
• set or read cookies;
• load additional resources;
• observe interactions;
• associate activity with an existing account.

This is why a screenshot is privacy-different from an iframe

Compare:

Local screenshot
↓
served by your site
↓
no live connection
to original platform

with:

Live iframe
↓
loads external platform
↓
active third-party connection

They may look nearly identical to a visitor

The network architecture is completely different.

YouTube privacy-enhanced mode

YouTube offers a privacy-enhanced embedding mode.

The official YouTube embedding documentation uses:

youtube-nocookie.com

for privacy-enhanced embedded players.

This reduces certain personalization behavior

According to YouTube, views through privacy-enhanced mode are not used to personalize the viewer’s YouTube browsing experience, and advertisements shown there are non-personalized.

Privacy-enhanced does not mean no external request

The visitor still connects to YouTube infrastructure.

This distinction is important

privacy-enhanced embed
≠
locally hosted content

Use two-click or consent-gated embeds where appropriate

A common privacy architecture is:

page loads
↓
local placeholder shown
↓
external iframe not loaded
↓
visitor chooses to activate
↓
external resource loads

This prevents the third-party connection from occurring immediately

The exact legal requirements for when and how consent is needed depend on jurisdiction and processing purpose.

Technically, however, deferred loading is very different from cosmetic overlaying

This:

iframe loads
↓
banner covers iframe
↓
user clicks Accept

is not the same as:

iframe absent
↓
user chooses
↓
iframe created

If the external request already happened, the placeholder came too late

A consent interface should control resource loading, not merely cover content after it has been loaded.

WordPress oEmbed discovery

WordPress supports oEmbed providers and discovery mechanisms for supported content.

The provider architecture makes publishing convenient.

But convenience does not remove the need to review frontend behavior

A content editor may paste:

https://external-platform.example/post/123

without realizing that the resulting embed introduces:

• remote JavaScript;
• remote fonts;
• iframes;
• tracking endpoints.

Content governance therefore matters

Privacy is not purely a plugin configuration problem.

Editors can add third-party dependencies through content.

Disabling oEmbed can reduce automatic embedding behavior

If a project does not need it, see How to Disable oEmbed in WordPress.

Do not disable it only because the word privacy appeared in a meeting

Determine what functionality the website actually uses.

Gravatar

WordPress traditionally integrates with Gravatar for user avatars.

A page can therefore render remote avatar URLs associated with email-derived identifiers.

The visible result is simple

small profile picture

The architecture can be less simple

WordPress knows user email
↓
creates Gravatar identifier
↓
page contains Gravatar URL
↓
visitor browser loads avatar
from external infrastructure

The email address is not normally transmitted in plaintext in that avatar URL

WordPress historically derives a hash-like identifier from the normalized email address.

But hashing does not make the underlying privacy question disappear

Email addresses can have a relatively searchable domain compared with random secrets, and public avatar identifiers can create linkability concerns depending on usage.

See How Gravatar exposes WordPress user emails for the dedicated analysis.

Remote avatars also create frontend requests

Even if you are not concerned about recovering the original identifier, loading an external image still creates:

visitor
↓
Gravatar infrastructure

Local avatars change that path

With local profile images:

visitor
↓
your WordPress media infrastructure

Maps

Interactive maps are another common source of external requests.

A typical map can load

• JavaScript SDKs;
• map tiles;
• geocoding services;
• fonts;
• API endpoints.

A static map image can be much simpler

Depending on the requirement:

interactive map
→ many requests + JavaScript

static image
→ one controlled resource

plain address/link
→ potentially zero third-party
  requests until user clicks

Use the least complex solution that meets the user need

If the page only needs to communicate:

We are located at this address.

an entire interactive mapping application may be excessive.

Captcha and anti-abuse systems

CAPTCHA services are commonly loaded on:

• contact forms;
• registration forms;
• login pages;
• checkout.

They are security tools

But they can also introduce third-party JavaScript and network requests.

Privacy and security can involve tradeoffs

A third-party anti-bot system may reduce fraud and abuse while introducing external processing.

The correct decision is not

privacy good
security bad

or:

security good
privacy irrelevant.

Evaluate both

Questions include:

• Is the service necessary?
• What data does it receive?
• Can it be delayed until needed?
• Is there a more privacy-preserving alternative?
• What contractual and legal safeguards exist?

Payment providers

Payment services often require third-party communication.

For example:

checkout page
↓
payment SDK
↓
provider tokenization
↓
payment infrastructure

This can be intentional and necessary functionality

Privacy engineering is not about eliminating every external service.

It is about reducing unnecessary processing and understanding necessary processing

A payment gateway handling card data can be a far better security architecture than storing payment-card information directly inside WordPress.

Third-party does not automatically mean worse

Sometimes external specialization improves:

• security;
• availability;
• compliance;
• fraud prevention.

But it must still be documented and configured properly

Chat widgets

Live chat commonly loads a substantial third-party application into the page.

It may involve:

• JavaScript;
• persistent connections;
• cookies;
• visitor identifiers;
• conversation history;
• user-account data.

Loading chat globally may be unnecessary

Ask whether it needs to appear on:

every article
every login page
every checkout page
every legal page

Conditional loading reduces exposure and performance cost

For example:

support page
→ load chat

blog archive
→ no chat

Social widgets

Social sharing and follow widgets can load:

• remote scripts;
• icons;
• iframes;
• tracking infrastructure.

A simple hyperlink often accomplishes the real goal

Compare:

<a href="https://social.example/company">
    Follow us
</a>

with:

500 KB social SDK
+
tracking
+
iframe
+
network requests

If the goal is merely navigation

a normal link is often enough.

The third-party request then happens only after the user intentionally leaves the site

Content delivery networks

CDNs require more nuanced analysis.

Suppose your images are served from

cdn.example.com

through a CDN provider.

The visitor’s request still reaches CDN infrastructure

But the CDN may be operating as part of your delivery chain rather than as an independent embedded application.

Privacy questions still exist

Such as:

• logging;
• data location;
• retention;
• processor terms;
• security;
• subprocessors.

But do not place a CDN, YouTube iframe and advertising pixel into one conceptual bucket

They are all external connections.

The purposes and processing contexts are very different.

Server-side requests vs. browser-side requests

This distinction is extremely important.

A browser-side request looks like

Visitor browser
↓
third-party.example

A server-side request looks like

Visitor
↓
WordPress server
↓
third-party.example

The third party sees different network information

In the second model, the remote API may see:

WordPress server IP

rather than:

visitor IP

But WordPress may still send personal data in the request payload

For example:

{
    "email": "customer@example.com",
    "order_id": 1234
}

Server-side proxying is not automatically private

It changes what the remote party receives directly from the browser.

It does not make intentionally transmitted application data disappear.

A privacy audit therefore needs both sides

BROWSER NETWORK REQUESTS

and

SERVER-SIDE HTTP REQUESTS

Browser DevTools reveals only the first category

A plugin might call:

wp_remote_post()

to send data from the server.

The browser may show no corresponding external request

Yet data still leaves the WordPress installation.

WordPress HTTP API

Plugins commonly communicate with external APIs through functions such as:

wp_remote_get()
wp_remote_post()
wp_remote_request()

Common legitimate uses include

• license checks;
• software updates;
• payment APIs;
• shipping APIs;
• AI APIs;
• security feeds;
• currency data.

The important question is what gets transmitted

For example:

Plugin version
Site URL
License key

has different privacy implications from:

User email
Full IP address
Form submission
Order details

Audit the request payload

Do not evaluate external APIs merely from the name of the provider.

Plugin telemetry

Telemetry can include:

• active plugin version;
• WordPress version;
• PHP version;
• feature usage;
• site identifiers;
• environment information.

Some telemetry is useful for software development

It can reveal:

• which features are used;
• which PHP versions need support;
• where errors occur.

But telemetry should not be invisible

WordPress plugin privacy guidance specifically asks developers to disclose whether their plugins collect telemetry directly or indirectly.

Opt-in is often preferable for non-essential telemetry

The exact policy depends on context and applicable law.

Do not make telemetry operationally indistinguishable from a required update check

These purposes are different:

Check whether security update exists
≠
collect detailed usage analytics

Remote license validation

Premium WordPress software may need to contact a license server.

A license request might send

license key
site URL
plugin version
installation identifier

The request may be functionally necessary for licensed updates

But it should still be documented.

Minimize the request payload

If the license server needs:

site URL
+
license key

there may be no reason to additionally send:

administrator email
site visitors
full plugin list
database contents

Data minimization is an engineering principle too

Before transmitting a field, ask:

Does the remote service
actually require this?

Privacy-friendly architecture often begins with fewer dependencies

Compare two sites.

Site A

local CSS
local fonts
local images
no social widgets
deferred video embeds
minimal analytics

Site B

remote CSS framework
Google Fonts
social SDK
three analytics systems
heatmap
live chat
YouTube
map embed
ad pixel
remote icon library

Site B has a larger privacy surface before anyone submits a form

It also has a larger:

• performance surface;
• security surface;
• availability surface.

Privacy and performance often point in the same direction

Reducing third-party requests can improve:

• page speed;
• DNS overhead;
• TLS connection overhead;
• resilience;
• privacy;
• auditability.

Fewer external dependencies mean fewer organizations involved in a page load

That does not mean:

zero external services
at all costs.

It means avoiding dependencies whose value does not justify their cost.

First-party does not automatically mean private

This is another important misconception.

A website can collect extensive personal data entirely through:

example.com

For example

local analytics endpoint
↓
captures every click
↓
stores visitor profiles
for five years

No external request occurs

But substantial processing still occurs.

Third-party auditing is one part of privacy engineering

It does not replace reviewing:

• what WordPress stores;
• cookies;
• forms;
• user accounts;
• logs;
• retention;
• exports;
• deletion workflows.

Conversely, third-party requests can matter even when little is stored locally

A site may have:

empty local database

while loading multiple remote tracking systems.

Local storage is not the only place privacy-relevant processing occurs

WordPress privacy tools

WordPress includes administrative privacy functionality intended to help site owners manage personal-data workflows.

Core provides tools around

• privacy-policy guidance;
• personal-data export;
• personal-data erasure.

Plugins can integrate with these systems

The official WordPress Plugin Handbook privacy documentation describes APIs plugin developers can use to:

• suggest privacy-policy content;
• register data exporters;
• register data erasers.

These tools do not magically discover every third-party request

They solve a different part of the problem.

A privacy-policy generator cannot inspect every remote API automatically

The site owner and plugin developers still need to understand their architecture.

Privacy policy text is not a technical control

This deserves emphasis.

Writing:

We respect your privacy.

does not alter the browser network graph.

If a script loads before consent, the privacy policy cannot retroactively unload it

Documentation and implementation must agree.

Consent management

Where consent is the applicable legal basis, consent management must control the relevant processing.

Technically, this often means preventing a resource from loading

Before consent:

analytics script
→ not loaded

marketing pixel
→ not loaded

non-essential iframe
→ placeholder only

After consent

resource activated
↓
external connection begins

A banner alone is not consent enforcement

Bad architecture:

page loads
↓
analytics already fires
↓
video already loads
↓
tracking pixel already fires
↓
banner appears:
"Accept?"

The decision arrived after the processing

If consent is required for those resources, execution needs to be gated correctly.

Do not block technically necessary resources casually

Some external calls may be necessary for:

• security;
• payment;
• authentication;
• fraud prevention;
• requested functionality.

Consent categories should follow actual purposes

Not every script should be labeled:

Necessary

because the developer would prefer not to implement conditional loading.

Audit what the code actually does

How to audit third-party requests in WordPress

The most useful starting point is the browser’s developer tools.

Step 1: open a private browser session

This avoids:

• administrator cookies;
• browser extensions affecting the page;
• cached consent state;
• logged-in differences.

Step 2: open Developer Tools

Go to:

Network

Step 3: disable cache during the test

Otherwise some resources may not appear because the browser already has them locally.

Step 4: reload the page

Now inspect every request.

Group by domain

You may see something like:

example.com
cdn.example.com
fonts.gstatic.com
youtube.com
analytics.example
gravatar.com

Step 5: distinguish your controlled infrastructure from external services

Create a simple inventory:

Domain
Purpose
Source
Necessary?
Loads before consent?
Data sent?
Owner/provider?

Example

fonts.example
Font delivery
Theme
No
Yes
Connection metadata
External provider

Step 6: inspect initiators

Developer Tools can often reveal which:

• script;
• stylesheet;
• iframe;
• HTML element;

triggered a request.

This helps identify the WordPress source

For example:

fonts.googleapis.com
↓
initiator:
theme-style.css

suggests the theme is responsible.

Another example

analytics-provider.example
↓
initiator:
plugin-analytics.js

Step 7: inspect request and response headers

Look for:

• cookies;
• referrer;
• query parameters;
• custom identifiers;
• cache behavior.

Step 8: inspect storage

Developer Tools normally provides views for:

• cookies;
• local storage;
• session storage;
• IndexedDB.

A request audit and storage audit complement each other

A provider can receive data without storing a browser cookie.

A script can also store browser data after it loads.

Step 9: test before consent

Clear:

• cookies;
• storage;
• consent state.

Reload without accepting anything

Record what already loads.

Step 10: accept one consent category

Compare the network log.

Step 11: reject optional categories

Confirm the resources remain blocked.

Do not merely trust the banner UI

Network activity is the evidence.

Step 12: test multiple pages

At minimum consider:

• homepage;
• article;
• contact page;
• login page;
• checkout;
• account area.

Different templates load different resources

Step 13: test interactive events

Some resources load only after:

• scrolling;
• opening chat;
• playing a video;
• submitting a form;
• opening checkout.

A page-load-only audit can miss them

Step 14: audit logged-in WordPress

Administrator screens may use external services that anonymous visitors never see.

Examples include

• remote plugin dashboards;
• license APIs;
• AI services;
• external fonts;
• Gravatar.

Administrator privacy still matters

A request does not stop being data processing because the user has the Administrator role.

Step 15: audit server-side requests

Browser DevTools cannot reveal these automatically.

Review:

• plugin documentation;
• source code;
• HTTP API hooks;
• application logs;
• provider dashboards.

Search plugin code for HTTP calls

Useful strings include:

wp_remote_get(
wp_remote_post(
wp_remote_request(
Requests::request(
curl_
file_get_contents( 'https://

This is not complete detection

Libraries may abstract the request.

But it is a useful starting point.

Step 16: audit embeds stored in content

Search posts and pages for:

• YouTube;
• Vimeo;
• maps;
• social posts;
• external iframes.

Editors can create privacy dependencies without installing plugins

Step 17: audit the theme

Look for remote:

• fonts;
• icon libraries;
• JavaScript CDNs;
• background images;
• CSS frameworks.

Step 18: document the result

A useful third-party inventory might contain:

Provider:
YouTube

Resource:
Embedded video

Pages:
Product tutorial pages

Load timing:
After user activation

Data:
Network/request metadata;
provider-specific data

Reason:
User-requested video playback

This inventory becomes operational documentation

It can support:

• privacy-policy maintenance;
• consent configuration;
• vendor reviews;
• security reviews;
• site migrations.

Privacy audits should be repeated

A WordPress site changes whenever somebody:

• installs a plugin;
• changes theme;
• adds a marketing tool;
• pastes an embed;
• switches CDN;
• adds chat;
• changes analytics.

A clean audit today does not guarantee a clean architecture next month

Performance tools can help find privacy dependencies

Tools that report:

• request domains;
• third-party JavaScript;
• connection counts;
• resource waterfalls;

can also reveal privacy-relevant dependencies.

This overlap is useful

A waterfall showing:

14 different external domains

is simultaneously:

• a performance clue;
• a resilience clue;
• a privacy clue.

How to reduce third-party requests

1. Remove services nobody uses

Old tracking scripts frequently survive long after campaigns end.

Common leftovers include

• retired analytics;
• old advertising pixels;
• abandoned chat widgets;
• A/B testing systems;
• marketing automation.

The best privacy configuration for an unnecessary service is deletion

No consent framework is more efficient than:

resource does not exist.

2. Self-host static assets where appropriate

Good candidates can include:

• fonts;
• icons;
• small JavaScript libraries;
• CSS frameworks.

But self-hosting has maintenance responsibility

You now manage:

• updates;
• security patches;
• cache headers;
• file integrity.

Do not copy a library locally and forget it forever

Privacy improvements should not create abandoned vulnerable dependencies.

3. Replace widgets with links

Instead of:

live social feed

consider:

Follow us on Platform

as a normal hyperlink.

4. Replace live embeds with local previews

For video:

thumbnail
+
play button
+
user activation
+
external embed

5. Load services only where they are needed

Example:

maps
→ contact page only

payment SDK
→ checkout only

chat
→ support pages only

6. Load optional services only after the correct trigger

This may be:

• user consent;
• user click;
• opening a specific widget.

7. Use server-side integrations where appropriate

This can reduce direct browser exposure.

But inspect the server-side payload

Otherwise you merely moved the request somewhere less visible.

8. Use local avatars

If Gravatar is unnecessary, local profile images can remove that remote asset path.

9. Disable unused embed functionality

See How to Disable oEmbed in WordPress.

10. Audit plugin settings

Plugins may provide optional toggles for:

• telemetry;
• remote fonts;
• CDN libraries;
• marketing scripts;
• external avatars.

11. Prefer locally bundled frontend assets

A plugin requiring a 30 KB JavaScript library usually does not need to fetch it from a public CDN merely because copying a CDN URL was convenient during development.

12. Remove unused WordPress assets where appropriate

For example, if a site does not use embedding functionality, reducing related scripts can improve both the request graph and page weight.

Do not disable functionality blindly

Audit first.

Privacy-friendly does not mean breaking the site elegantly

What about WordPress emojis?

Modern WordPress versions have evolved their emoji implementation over time.

Before disabling anything for privacy reasons, inspect what your current WordPress version actually loads.

Do not rely on a 2017 performance tutorial as an infrastructure map for 2026

Core changes.

Plugins change.

Browsers change.

Always audit the current page

Remote JavaScript deserves special scrutiny

Compare a remote image:

browser downloads bytes

with remote JavaScript:

browser downloads bytes
↓
executes code
↓
code can make more requests
↓
code can inspect page/browser state

This gives remote JavaScript significantly more capability

Questions to ask include:

• Who operates it?
• Can it change without your deployment?
• What does it execute?
• What additional hosts does it contact?
• Does it read cookies or storage?

Third-party JavaScript is also a supply-chain risk

If:

https://third-party.example/widget.js

changes tomorrow, your page can execute different code tomorrow without a WordPress deployment.

Privacy, security and operational control intersect here

Subresource Integrity can help in some static-library cases

For immutable external scripts, browsers support:

integrity=

attributes that can verify a known resource hash.

But SRI is not a privacy mechanism

The browser still contacts the external host.

It protects integrity, not network disclosure

Referrer Policy can reduce information leakage

Browsers can include a:

Referer

header when requesting or navigating to external resources.

A site’s Referrer-Policy can restrict what is transmitted

For example, policies can reduce exposure of full paths to other origins.

This is useful defense in depth

But it does not eliminate:

IP address
connection itself
explicit query parameters
cookies sent to that domain

Use privacy controls for the problem they actually solve

Content Security Policy can help inventory and control connections

A Content Security Policy can define allowed sources for:

• scripts;
• styles;
• fonts;
• images;
• frames;
• connections.

For example

script-src 'self';

font-src 'self';

frame-src https://www.youtube-nocookie.com;

A strict CSP can block unexpected third-party resources

That provides both:

• security benefits;
• architectural visibility.

But CSP is not a privacy policy

It enforces browser resource restrictions.

It does not determine:

• legal basis;
• retention;
• processor agreements;
• user rights.

Use it as technical enforcement

Server logs are another privacy surface

Even a website with no analytics often has:

web server access logs

Those logs commonly contain

• IP addresses;
• timestamps;
• requested URLs;
• status codes;
• user agents;
• referrers.

Removing Google Analytics does not eliminate all data processing

Infrastructure still exists.

Privacy engineering needs the whole system

browser
+
WordPress
+
database
+
logs
+
CDN
+
third-party APIs
+
backups

Backups matter too

When personal data is deleted from the live database, historical backups may still contain previous copies.

This is not specifically a third-party-request problem

But backup vendors can also become external processors if backups are stored remotely.

Document retention and restoration procedures

A restored old backup can reintroduce data previously removed from production.

External AI APIs

Modern WordPress sites increasingly connect to AI services for:

• alt-text generation;
• content generation;
• SEO suggestions;
• translation;
• support chat.

This creates a new class of server-side third-party request

For example:

WordPress
↓
image uploaded
↓
image or metadata sent
to AI provider
↓
generated result returned

Inspect exactly what is transmitted

Possible data can include:

• image bytes;
• page content;
• titles;
• user-entered text;
• site metadata.

Do not send entire database records when the model needs one sentence

Minimize context to what the operation actually requires.

API keys are also sensitive

They should remain server-side whenever possible.

Do not expose secret API keys in frontend JavaScript

That is simultaneously:

• a security issue;
• a billing issue;
• an excellent gift to strangers.

WordPress privacy and plugin design

A well-designed plugin should be able to answer:

Does it contact external servers?

When?

Why?

What does it send?

Can the feature be disabled?

Does it load remote frontend resources?

Developers should document this clearly

WordPress provides:

wp_add_privacy_policy_content()

so plugins can suggest relevant information for the site’s privacy policy.

This is useful when a plugin processes personal data

Especially when it:

• shares data externally;
• collects telemetry;
• stores user information;
• uses third-party SDKs.

Documentation should reflect optional features

If a plugin contacts an external API only when:

AI feature enabled

say that.

Do not describe conditional processing as universal

And do not describe always-on processing as optional.

How to evaluate a WordPress plugin for third-party requests

Check its privacy documentation

Look for:

• external APIs;
• telemetry;
• remote assets;
• data retention.

Install it on a test site

Compare network activity:

before activation

vs.

after activation

Enable features one at a time

This helps identify which component introduces a request.

Inspect source code

Search for:

http://
https://
wp_remote_
iframe
script src
link href

Inspect scheduled tasks

Some telemetry or API communication may run through:

WP-Cron

rather than visitor requests.

Inspect admin-only behavior

Plugins sometimes load marketing dashboards or remote news feeds only in:

wp-admin

Ask whether external access is functionally necessary

A syntax-highlighting library probably does not need to phone home.

Third-party request risk matrix

LOWER COMPLEXITY

Local static asset
↓
your infrastructure


MODERATE

CDN serving your assets
↓
external infrastructure
under delivery relationship


HIGHER INTERACTION

Remote font / image
↓
external connection


MORE CAPABILITY

Third-party JavaScript
↓
external executable code


EMBEDDED APPLICATION

iframe / social embed / map
↓
external service inside page


ACTIVE DATA EXCHANGE

Analytics / ads / chat / API
↓
purposeful data transfer

This is not a legal classification

It is an engineering model for understanding increasing external involvement.

A WordPress third-party request checklist

• Open the site in a private browser window.
• Inspect the Network panel with cache disabled.
• List every hostname contacted.
• Identify the organization behind each hostname.
• Identify what WordPress component initiated each request.
• Separate theme requests from plugin requests.
• Audit content embeds.
• Audit remote fonts.
• Audit analytics.
• Audit advertising scripts.
• Audit maps.
• Audit CAPTCHA.
• Audit chat systems.
• Audit social widgets.
• Audit Gravatar usage.
• Audit payment integrations.
• Audit CDN configuration.
• Inspect cookies and browser storage.
• Inspect request query strings.
• Inspect referrer behavior.
• Test the site before consent.
• Test after accepting individual consent categories.
• Test rejection of optional categories.
• Verify blocked resources genuinely remain unloaded.
• Test multiple page templates.
• Test interactive widgets.
• Test the login page.
• Test checkout where applicable.
• Audit logged-in wp-admin.
• Audit server-side HTTP requests.
• Review plugin telemetry.
• Review remote license validation.
• Review external AI integrations.
• Remove services that are no longer needed.
• Self-host appropriate static assets.
• Replace widgets with simple links when possible.
• Use consent-gated embeds where appropriate.
• Load services only on pages that require them.
• Maintain an external-service inventory.
• Update privacy documentation when the stack changes.

A third-party request decision tree

Page contacts external domain
│
├── Why?
│
├── Is it necessary?
│   │
│   ├── No
│   │   └── Remove it
│   │
│   └── Yes
│       │
│       └── Can it be
│           self-hosted?
│           │
│           ├── Yes
│           │   └── Evaluate
│           │       local hosting
│           │
│           └── No
│               │
│               └── Can loading
│                   be deferred?
│                   │
│                   ├── Yes
│                   │   └── Load
│                   │       when needed
│                   │
│                   └── No
│                       └── Document,
│                           secure and
│                           minimize

A consent-loading decision tree

Optional third-party service
│
└── Is consent required
    for this implementation?
    │
    ├── Yes
    │   │
    │   ├── Before consent
    │   │   └── resource NOT loaded
    │   │
    │   └── After consent
    │       └── resource loaded
    │
    └── No
        └── Document appropriate
            processing basis
            and implementation

A browser vs. server decision tree

External service used?
│
├── Browser connects directly?
│   │
│   └── Inspect:
│       IP exposure
│       headers
│       cookies
│       storage
│       JavaScript
│
└── WordPress server connects?
    │
    └── Inspect:
        request payload
        identifiers
        retention
        API purpose

Common WordPress privacy mistakes

Looking only for cookies

External requests can matter even without cookies.

Assuming every third-party request is tracking

A CDN or payment gateway may serve a different purpose from an advertising pixel.

Assuming every first-party request is private

First-party analytics can still process extensive personal data.

Loading optional trackers before consent

A banner cannot reverse a request that already occurred.

Covering an already-loaded iframe with a consent placeholder

The external connection has already happened.

Assuming youtube-nocookie.com means YouTube is no longer contacted

Privacy-enhanced mode still uses YouTube infrastructure.

Ignoring Gravatar

An innocent-looking avatar can introduce an external resource request.

Ignoring remote fonts

Typography is still network infrastructure.

Ignoring admin pages

WordPress administrators are users too.

Auditing only the homepage

Checkout, login, forms and article embeds may use completely different services.

Auditing only browser traffic

Server-side API requests are invisible in DevTools.

Installing a consent plugin and assuming the job is finished

The configuration still has to map correctly to actual resources.

Keeping retired marketing scripts forever

Unused third-party dependencies have approximately zero upside.

Self-hosting obsolete libraries and never updating them

Privacy improvements should not produce security regressions.

Calling every third-party resource necessary

Business convenience and technical necessity are not identical concepts.

Sending excessive data to external APIs

Only transmit what the service genuinely needs.

Publishing a privacy policy that does not match the implementation

Documentation cannot compensate for inaccurate technical behavior.

Quick reference: common third-party request sources

Google Fonts
→ remote font delivery

YouTube / Vimeo
→ embedded video

Maps
→ map SDK + tiles

Gravatar
→ remote avatars

Analytics
→ measurement

Ad pixels
→ advertising / conversion

Social widgets
→ platform integration

Chat
→ real-time support

CAPTCHA
→ abuse prevention

Payment gateway
→ payment processing

CDN
→ asset delivery

License server
→ software entitlement

AI API
→ generated or analyzed content

Quick reference: alternatives

Remote font
→ self-host font

Live social widget
→ normal link

Immediate video iframe
→ local preview + click

Interactive map
→ static map / address link

Remote avatar
→ local avatar

Global script
→ page-specific loading

Optional tracking
→ consent-gated loading

Unused service
→ delete it

Related WordPress privacy, embeds and asset guides

For the wider privacy, external-resource and performance cluster, continue with:

• How Gravatar exposes WordPress user emails
• Self-hosting Google Fonts in WordPress
• Self-Hosted Fonts vs. Google Fonts in WordPress
• CDN vs. self-hosted assets in WordPress
• Why Third-Party Embeds Slow Down WordPress
• How to Disable oEmbed in WordPress
• How to disable oEmbed in WordPress
• Why web fonts cause layout shift and how to avoid it
• WordPress login hooks explained
• Preparing a WordPress site for launch

Final thoughts

WordPress privacy is not limited to:

cookies
+
privacy policy
+
consent banner

A modern WordPress page is a network application.

The browser may communicate with several services before the visitor clicks anything.

Understanding privacy therefore starts with understanding the data path:

Visitor
↓
WordPress
↓
Which other systems
receive a request?

For every third-party dependency, ask:

Why is it here?

What does it receive?

Does it need to load now?

Can it be removed?

Can it be self-hosted?

Can it be delayed?

Is the processing documented?

The goal is not necessarily to create a WordPress site that never communicates with anything outside its own server.

That can be unrealistic for payments, security, video, transactional services and many other legitimate features.

The goal is to make every external connection intentional.

A privacy-conscious architecture usually moves from:

Install service
↓
load everywhere
↓
wonder what it does later

to:

Define requirement
↓
choose provider
↓
minimize data
↓
control loading
↓
document processing
↓
audit periodically

That approach also tends to produce faster, more secure and easier-to-maintain WordPress sites.

Which is convenient, because removing six marketing scripts nobody remembers installing is one of the rare situations where privacy, security, performance and basic housekeeping all manage to agree on something.