Immer wieder entstehen Gerüchte rund um WordPress, die sich aus irgendeinem Grund weit verbreiten, aber die selten einen realen Grund haben. Diese Mythen möchte ich in diesem Beitrag analysieren und aufzeigen, welcher Aspekt stimmt und welcher nicht.
Disclaimer
Es gibt bereits zahlreiche Websites, die Mythen rund um WordPress auflisten. Diese haben oft die Absicht durch Keywords Aufmerksamkeit zu erregen und dadurch wiederum Umsatz für den Ersteller. Mein Beitrag hier verfolgt nicht dieses Ziel. Ich möchte nur gerne eine textliche Basis haben, auf die ich verlinken kann, wenn mal wieder jemand Mythen über WordPress verbreitet.
Bitte beachtet, dass der Artikel aktualisiert werden könnte. Neue Mythen kommen dazu, neue vermeintliche Begründungen entstehen – diesen möchte ich auch in Zukunft hier begegnen.
„WordPress.org sperrt meine IP-Adresse“
Auf diese Aussage trifft man leider oft, wenn man im Support Team von wordpress.org tätig ist. Grund ist immer eine Meldung im Website-Zustand oder beim Abrufen von Plugin-Updates aus dem Repository, dass der Server von wordpress.org nicht erreicht werden konnte.
Für diese Meldungen kann es viele Gründen geben:
- In WordPress könnte ein Plugin ausgehende Requests filtern oder sperren. Es lohnt sich zunächst zu schauen, ob man ein Sicherheitsplugin nutzt, was das verursacht.
- Eine Firewall im eigenen Hosting sperrt ausgehende Requests, manchmal auch nur selektiv. Um das abzuklären, sollte man sich an den eigenen Hoster wenden.
- Das Rechenzentrum des Hosters, in dem die Website liegt, könnte den Zugriff für ausgehende Requests beschränken. Auch das ist meist eine Firewall und auch hier kann nur der Hoster helfen.
- Es kann ein Routing-Problem vom Standort der Website zu wordpress.org die Ursache sein. Das kommt selten vor, aber es passiert. Testen kann man das (wenn man entsprechenden Zugriff hat) mit traceroute, welches jeden einzelnen Knoten auflistet über den der Request von der Website zu wordpress.org geht. Auch hier kann das Support des eigenen Hosters helfen.
Im ganz seltenen Fall, dass wordpress.org tatsächlich nicht erreichbar ist, lohnt ein Blick auf die Status-Seite: https://status.wordpress.org
Für die Verwaltung der Technik, die wordpress.org nutzt, ist übrigens das Systems-Team zuständig: https://make.wordpress.org/systems/ – wenn ihr doch mal Fragen zu vermeintlicher Nicht-Erreichbarkeit habt, meldet euch aber eher beim Meta-Team im Slack. Die geben das ggfs. an Systems weiter oder helfen bei der weiteren Analyse.
Fakt ist: eure IP-Adresse wird nicht durch wordpress.org geblockt. Die Ursache liegt in 99% der Fälle woanders.
„WordPress hat eine eingebaute KI“
Fakt ist: es gibt keine KI in WordPress Core. Ihr könnt selbst entscheiden, ob und welche ihr nutzt – oder auch einfach drauf verzichten.
Warum es zu diesem Mythos kommt, ist denke ich einer unglücklichen Kommunikation wie auch dem mangelnden Leseverständnis einiger Mitmenschen zu verdanken. Mit WordPress 7.0 wurden die Konnektoren eingefügt. Damit möchte WordPress es ermöglichen, externe APIs an einer zentralen Stelle zu verwalten. In der offiziellen Neuigkeit von wordpress.org zu WordPress 7.0 prangt ganz groß die Zwischenüberschrift „AI-Integrated WordPress“ – was als Marketingspruch sehr markig klingt, aber inhaltlich eben nicht richtig ist. Denn WordPress integriert keine KI.
Konnektoren ermöglichen die Anbindung von APIs. Diese können natürlich sehr vielfältig sein. WordPress selbst hat die REST API um auf Daten von Projekten zuzugreifen; viele Social Media Plattformen haben APIs um auch dort Daten bereitzustellen. Auf Grund der Aktualität entschied man sich in der Community für das Release von WordPress 7.0 zunächst die Möglichkeit bereitzustellen, APIs von KIs anzubinden. Und genau dazu kann man im Backend unter Einstellungen > Konnektoren eben diese verwalten – oder auch einfach ignorieren.
Um KI auf diesem neuen Weg zu verwenden, muss man:
- Einen Konnektor mit euren persönlichen API-Zugangsdaten konfigurieren.
- Ein Plugin installieren, was darauf zugreift und die AI hinter dem Konnektor anspricht.
Solange kein Konnektor konfiguriert ist und ihr nicht bewusst ein Plugin aktiviert habt, was diese verwendet, wird auch keine KI verwendet.
Nochmal: WordPress bringt keinesfalls selbst eine KI mit, sondern stellt nur den Weg dafür bereit. Ob man ihn nutzt oder nicht, ist jedem selbst überlassen.
Und ja, man kann mit
add_filter( 'WP_AI_SUPPORT', '__return_false' );den KI Support abschalten. Das verhindert, dass ein konfigurierter Konnektor von einem dafür installierten Plugin verwendet wird. Hat man beides nicht, braucht man diese Zeile auch nicht verwenden. Man kann ebenso einfach den einen neuen Menüpunkt im Backend ignorieren.
Übrigens wird es auch persektivisch keine native KI in WordPress geben. Dagegen spricht der Fakt, dass der Release-Zyklus von neuen KI-Modellen einfach wesentlich schneller ist als der von WordPress. Eine im WordPress Core eingebaute KI bräuchte alle paar Wochen ein Update – das kann man viel besser per Plugins leisten als mit neuen WordPress Releases, die es nur geben müsste um hier mitzuhalten. Daher obliegt es euch als Nutzer, ob und wie ihr KI in euren WordPress-Projekten nutzt.
„Die von WordPress“
WordPress ist eine Open Source Software, entwickelt in Abstimmung zwischen tausenden weltweit verteilten Enthusiasten. Es gibt Teams, die sich auf bestimmte Aspekte spezialisiert haben – je nach eigenen Fähigkeiten kann jeder sich an einem Teil davon beteiligen und Einfluss nehmen.
Immer wieder treffe ich auf die Aussage „die von WordPress haben .. „. Das stößt mir immer wieder sauer auf, da es wie ein Fiebertraum mit Verschwörungstheorien klingt.
Fakt ist: alles was für die Software WordPress entwickelt wird, ist öffentlich einsehbar und nachvollziehbar.
Grenzen gibt es dabei lediglich bei Sicherheitsaspekten, die erst nach Bereitstellung einer Korrektur auch Veröffentlicht werden. Ein absolut normales Vorgehen in der Software-Branche, was seit Jahrzehnten auch duch „große Player“ wie Microsoft oder Oracle so gehandhabt werden.
Wenn ihr dazu fragen habt, was da entwickelt wurde, schaut euch die Quellen und die in ihnen dokumentierten Änderungen an:
Oder fragt einfach im Forum nach: https://wordpress.org/support/forums/
Und ja, das kostet etwas eurer Zeit. Wer sich diese jedoch nicht nimmt, sollte sich nicht über Dinge aufregen. Es steht euch frei, euch auch an dem Prozess zu beteiligen. Ganz egal was eure Fähigkeiten sind – auch Anwenderrückmeldungen sind jederzeit willkommen.
„WordPress ist langsam“
Auch diese Aussage wird mitunter als Argument gegen WordPress gebracht. Sie stimmt faktisch aber nicht.
Der WordPress Core ist äußerst performant. Ganz ohne Plugins und mit einem Standard-Theme ausgestattet, wird man keinerlei Nachteile spüren.
Geschwindigkeitsnachteile ergeben sich erst durch Plugins und Themes von anderen Entwicklern, je nachdem wie man diese im Projekt zusammengesteckt hat. Leider gibt es Entwickler, die kaum darauf achten und offenbar auch keinen Wert legen. Genau die sind es, die WordPress-basierte Projekte verlangsamen. Als Betreiber einer Website sollte man hierauf daher durchaus achten und möglicherweise Alternativen verwenden, wenn ein Plugin doch mehr Nachteile mit sich bringt als man erhofft hat.
Damit der WordPress Core weiterhin performant bleibt, gibt es übrigens auch ein Performance Team: https://make.wordpress.org/performance/ – deren Ergebnisse fließen seit Jahren regelmäßig in neue Releases ein.
Fakt ist: WordPress selbst ist superschnell. Euer WordPress ist so schnell wie ihr es entscheidet zu konfigurieren.
„WordPress ist ein reines Blog-System“
WordPress ist 2003 als Blog-System entstanden, ja. Es hat sich aber weitererentwickelt. Man mag drüber streiten, ob das gut oder schlecht ist. Faktisch kann man mit WordPress heutzutage aber eine Vielzahl von Anforderungen abdecken.
Schon der WordPress Core bietet ganz ohne Plugins wesentlich mehr Möglichkeiten als nur das Schreiben von Beiträgen. Man kann normale Websites mit mehreren Seiten erstellen – und in einer vlt. noch „Aktuelles“ unterbringen, was dann dem Bloggen entsprechen könnte. Aber man muss nicht.
Plugins erweitern diese Möglichkeiten ganz erheblich. Shopsysteme sind nur eines von vielen Beispielen, die man hier nennen kann.
Fakt ist: WordPress ist kein reines Blog-System. Es obliegt dem Website-Betreiber wofür er es verwendet.
„Plugins machen WordPress langsam“
Plugins sind ein wesentlicher Baustein, um mehr aus seinem WordPress-basierten Projekt zu holen. Sie erweitern die Grundfunktionen von WordPress um Lösungen mit denen man seine Ziele erst recht erreichen kann.
Sie werden von tausenden Entwicklern weltweit bereitgestellt. Trotz Vorgaben mittels der WordPress Coding Standards, sind manche Plugins strukturell dennoch schwierig aufgebaut und können zu Problemen führen. Entwickler stellen dagegen Aktualisierungen bereit, in denen sie Optimierungen dazu vornehmen. Leider gibt es hier technische wie auch menschliche Grenzen.
Fakt ist: Plugins per se machen WordPress nicht langsam. Aber sie können Schuld sein.
„WordPress ist unsicher“
Patchstack veröffentlich jährlich eine Statistik über die Sicherheit von WordPress. Im Bericht für 2025 liest man, dass 91% aller entdeckten Sicherheitslücken sich in Plugins befanden, 9% waren in Themes und lediglich 6 (Anzahl) im WordPress Core. Damit ist WordPress selbst sicherer als manch andere CMS, die im gleichen Zeitraum mehr Sicherheitslücken aufgewiesen haben.
Quelle: https://patchstack.com/whitepaper/state-of-wordpress-security-in-2026/
Und ja, die Plugins sind auch hier wieder das Problem. Ich sehe jedoch hier einen Fortschritt in jedem Jahr. Durch neue und bessere Vorgaben für das Plugin Repository, sind viele Entwickler gezwungen ihre Plugins sicherer zu machen. Der Cyber Ressiliance Act ab September 2026 betrifft die kostenfreien Open Source Plugins leider nicht, aber es ist zu hoffen, dass er auch hier das Bewusstsein weiter schärft.
Fakt ist: WordPress per se ist nicht unsicher, aber bei Plugins sollte man auf die Aktualität achten.
„Alles bei WordPress kostet etwas“
WordPress ist eine Open Source Software, die von jedem kostenfrei verwendet werden kann. Ja, es gibt den Baukasten unter wordpress.com – den zu nutzen ist jedoch jedem selbst überlassen.
Die Freiheit der Entwicklung im WordPress-Universum, ermöglicht es gleichzeitig aber auch Entwicklern kostenpflichtige Versionen ihrer kostenfreien Plugins anzubieten. Diese machen dafür natürlich auch Werbung, teilweise etwas zu intensiv, aber man muss darauf nicht eingehen.
Fakt ist: für die allermeisten Anwendungsfälle gibt es kostenfreie Lösungen in WordPress.
„WordPress und seine Plugins telefonieren nach hause“
Auch hier muss man differenzieren.
Ja, der WordPress Core greift ohne entsprechende Einstellungen z.B. auf das Repository zu um Plugins, Themes sowie aktuelle Sprachdateien zu laden. Dieser Ladevorgang wird seitens wordpress.org dazu verwendet Statistiken zu erfassen, die für die Weiterentwicklung von WordPress wichtig sind. Diesen Vorgang kann man, wenn man will, aber auch unterbinden, z.B. indem man jegliche Updates abschaltet. Dann muss man sich aber manuell um Aktualisierungen am eigenen Projekt kümmern.
Gleichzeitig wird auch noch Gravatar eingebunden, damit Avatare von Nutzern dargestellt werden. Auch das kann man einfach unter Einstellungen > Diskussion deaktivieren.
Das FAIR Projekt hat dafür auch eine interessante Lösung gebaut: deren Plugin schaltet alles ab was von WordPress nach außen gesendet wird. Das gleiche kann man aber auch mit anderen Plugins oder individuellen Codes erreichen.
Plugins im WordPress Repository ist es untersagt, Daten ohne Nachfrage nach außen zu schicken. Es gibt leider immernoch regelmäßig Fälle, in denen Plugins aus genau dem Grund gesperrt werden. Aber auch hier bessert sich die Qualität durch Optimierungen beim Plugin Team.
Kommerzielle Plugins dagegen können durchaus machen was sie wollen. Sie können nach Hause telefonieren, auch ganz ungefragt. Es ist jedoch jedem Website-Betreiber überlassen, diese Plugins zu nutzen – oder drauf zu verzichten und sich auf die Sicherheit mit den kostenfreien Plugins aus dem Repository zu verlassen.
Fakt ist: WordPress meldet ein paar Dinge an wordpress.org – kostenfreie Plugins im Repository dürfen das nicht, egal wohin. Und wer ein kostenpflichtiges Plugin nutzt, unterliegt deren gutem Willen.