Was lädt ein WordPress-Plugin von fremden Servern?

Die Frage

Welche WordPress-Plugins laden beim gewöhnlichen Seitenaufruf etwas von fremden Servern?

Das ist die Frage, die Agenturen ihren Kunden beantworten müssen, und sie wird üblicherweise mit Vermutungen beantwortet. Eine Messung dazu gab es nicht.

Die Methode

Je Plugin ein eigener WordPress Playground im Browser. Das Plugin wird aus dem Verzeichnis installiert und aktiviert, sonst wird nichts eingestellt. Danach wird abgemeldet die Startseite und ein Beitrag aufgerufen, so wie ein Besucher es tut. Jede Netzwerkanfrage wird mitgeschrieben und nach Gastgeber gruppiert.

Vier Entscheidungen machen das Ergebnis erst belastbar, dazu kommt die Stichprobe.

Grundlinie abziehen

Zuerst läuft ein Durchgang ganz ohne Plugin. Ergebnis: null fremde Gastgeber. WordPress mit dem mitgelieferten Theme holt von sich aus nichts von außen. Alles, was danach auftaucht, hat jemand installiert.

Es zählt der Rahmen, aus dem die Anfrage kommt

Gezählt wird nur, was aus dem WordPress-Rahmen kommt. Anfragen aus der Playground-Hülle sind Messumgebung. Warum eine Sperrliste von Gastgebern dafür untauglich ist, steht weiter unten bei den Fehlalarmen.

Abgemeldet messen, und erst nach dem Abmelden zählen

Die Frage lautet „beim Seitenaufruf“, also Frontend, ohne Anmeldung. Der Schnitt, ab dem gezählt wird, liegt hinter dem Abmeldevorgang. Warum das wichtig ist, zeigt der zweite Fehlalarm.

Nichts einstellen

Gemessen wird der Zustand direkt nach dem Aktivieren. Das ist reproduzierbar und es ist der Zustand, in dem die meisten Installationen bleiben.

Diese Einschränkung gehört in jeden Satz über das Ergebnis. Ein Plugin, das erst nach dem Verbinden eines Kontos Daten holt, steht hier zu Recht bei null, und es wäre falsch, daraus zu schließen, es hole nie etwas. Die Aussage lautet: aus der Packung heraus holt es nichts.

Die Stichprobe

Alle 67 Plugins mit mindestens einer Million Installationen aus dem Plugin Directory Census 01/2026, dazu die sechs eigenen. Die Auswahl ist damit definiert und nicht gegriffen: wer über eine Million Installationen hat, ist drin.

Ein Plugin ist ausgefallen: litespeed-cache. Der Playground kam in vier Anläufen nicht hoch, in keinem der beiden Modi. Gemessen wurden damit 72.

Die eigenen Plugins stehen in derselben Tabelle wie alle anderen. Es sind sechs der 72 Kennungen: hafen-core, hafenstudios-ads, heckgalerie, linkjet, wellenbrecher, wimpel.

Der Selbsttest: warum eine Null überhaupt etwas wert ist

Ein stilles Ergebnis ist nur dann eine Aussage, wenn das Messgerät beweisen kann, dass es ausschlägt. Der Selbsttest hängt über ein mu-Plugin eine bekannte Fremdanfrage ins Frontend:

$img = '<img src="https://example.com/hs-selbsttest.png" width="1" height="1" alt="" />';
add_action( 'wp_footer', function () { echo $img; } );

Gemessen am 16.09.2026, ohne jedes Plugin:

Grundlinie messen (ohne Plugin) ...
  1 fremde Gastgeber ohne Plugin: example.com

Die Kette steht also: Startseite geladen, abgemeldet, Rahmenfilter durchlässig, Anfrage erfasst. Eine Null in der Tabelle ist eine echte Null.

Zwei Fehlalarme, beide selbst produziert

Beide stehen hier, weil eine Messung ohne ihre Fehlversuche nicht prüfbar ist.

Elementor und Google Analytics

Der erste Durchgang meldete für elementor einen Treffer auf region1.google-analytics.com. Die Adresse verrät sich selbst:

dl=https%3A%2F%2Fplayground.wordpress.net%2F%3Fmode%3Dseamless
dt=WordPress%20Playground
en=error&ep.source=bootSiteClient

Das war die Statistik von playground.wordpress.net, die einen eigenen Startfehler meldet. Eine Sperrliste auf google-analytics.com wäre der falsche Ausweg gewesen: ein Plugin, das wirklich Analytics ins Frontend lädt, ist genau der gesuchte Befund. Deshalb entscheidet seitdem der Rahmen, aus dem die Anfrage kommt. elementor steht danach bei null.

wps-hide-login und Gravatar

Der zweite Durchgang meldete für wps-hide-login einen Treffer auf secure.gravatar.com. Der Rahmen im Protokoll:

https://playground.wordpress.net/scope:happy-quiet-valley/wp-login.php?action=logout

Das war die Adminleiste auf der Abmeldeseite, also WordPress-Kern auf einer Seite, die kein Besucher je sieht. Der Zählschnitt lag vor dem Abmelden statt danach. Nach dem Fix: null.

Ergebnis Frontend

Von 72 gemessenen Plugins holt genau eines beim gewöhnlichen Seitenaufruf etwas von einem fremden Server: hostinger-reach holt js/embed.js von cdn-reach.hostinger.com, zweimal, auf der Startseite.

Dieser Befund ist zweimal unabhängig gemessen worden, am 15.09. und am 16.09.2026, in beiden Läufen mit dem Rahmen der Startseite und abgemeldet.

Alle 72 gemessenen Plugins im Frontend, abgemeldet, direkt nach dem Aktivieren. Sortiert nach Anzahl der Anfragen, danach alphabetisch.

Die Frage unterstellt, dass viele Plugins beim Seitenaufruf nach außen funken. Gemessen tun sie das nicht, solange sie nicht eingerichtet sind. Site Kit ohne verbundenes Google-Konto lädt nichts. Instagram Feed ohne Konto lädt nichts.

Das Risiko entsteht mit der Einrichtung. Die Installation allein erzeugt es nicht. Wer Datenschutz prüft, sieht sich deshalb die eingerichteten Plugins an, und zwar jedes einzeln.

Ergebnis Backend

Von 72 gemessenen Plugins holen neun etwas von fremden Servern, sobald der Betreiber sein eigenes Backend öffnet. Jeder Befund ist zweimal unabhängig gemessen worden, am 16.09.2026, und beide Läufe stimmen überein.

Die Grundlinie im Backend liegt über null: angemeldet lädt WordPress von sich aus secure.gravatar.com für das Bild in der Adminleiste. Das wird abgezogen und zählt bei keinem Plugin mit.

Die neun Befunde im Backend, mit Fundort und Art der Anfrage.

google-analytics-for-wordpress (MonsterInsights) und optinmonster sind die beiden Fälle, in denen der Betreiber selbst weitergeschickt wird, bevor etwas eingerichtet ist. MonsterInsights landet auf connect.monsterinsights.com, die Adresse trägt mit: site_url=…, rest_url=…/wp-json/monsterinsights/v1, onboarding_key=…, return_url=…. OptinMonster landet auf app.optinmonster.com/wp-welcome, die Adresse trägt mit: connectionToken=…, wpUrl=…. Beide Plugins kommen aus demselben Haus.

Dazu lädt OptinMonster auf seiner Seite Adobe Fonts (use.typekit.net, acht Anfragen) und ein Zählpixel p.typekit.net/p.gif, das den Hostnamen der Website mitschickt (h=…).

Fünf der neun Fälle sind Schriften von Google Fonts. wp-smushit holt seine Schriften von fonts.bunny.net, und das geschieht auf der Plugin-Liste von WordPress.

Alle 72 gemessenen Plugins im Backend, angemeldet, direkt nach dem Aktivieren. Die Grundlinie von WordPress ist abgezogen. Sortiert nach Anzahl der Anfragen, danach alphabetisch.

Was die Messung nicht sagt

• Nichts über den eingerichteten Zustand. Wer ein Konto verbindet, bekommt andere Zahlen.
• Nichts über Anfragen, die der Server macht, statt der Browser. Ein Plugin, das serverseitig eine fremde Schnittstelle abruft, taucht hier nicht auf. Das ist eine eigene Messung wert.
• Nichts über die Inhalte der Anfragen. Gemessen wurde, dass etwas geholt wird, und von wem.

Rohdaten zum Nachrechnen

Je Plugin und Lauf liegt eine JSON-Datei vor. Sie hält den Gastgeber, die Anzahl der Anfragen, den Typ der Anfrage, die vollständigen Adressen und den Rahmen fest, aus dem die Anfrage kam. Dazu kommen die Grundlinie ohne Plugin und die Liste der gemessenen Kennungen.

Die beiden Tabellen auf dieser Seite sind aus genau diesen Dateien erzeugt, Zeile für Zeile. Die Spalte „Anfragen“ ist die Summe der Anfragen über alle fremden Gastgeber eines Plugins.

Das Messwerkzeug ist ein eigenes Skript (fremdanfragen.mjs), das den WordPress Playground steuert und das Netzwerkprotokoll auswertet. Wer die Dateien zum Nachrechnen möchte, schreibt an moin@hafenstudios.com.

Gemessen von

Gemessen am 15. und 16.09.2026 von hafenstudios, Hamburg.

Korrekturen und Widerspruch an moin@hafenstudios.com. Eine belegte Korrektur wird auf dieser Seite nachgetragen.