Drei Viertel des Webs sprechen noch PHP. Klingt verrückt? Die Zahl hält sich hartnäckig, weil WordPress, WooCommerce & Co. den Long Tail dominieren. Wer hier gelandet ist, will eine saubere Antwort mit belastbaren Quellen, nicht noch eine Meinungsrunde. Du bekommst: frische Zahlen für 2025, wie sie gemessen werden, wo PHP stark ist (und wo nicht), plus eine schnelle Entscheidungs- und Migrations-Checkliste.
Kurzfassung & harte Zahlen 2025
Wenn du nur eine Zahl mitnehmen willst: Laut W3Techs (Stand: August 2025) nutzen rund 76-77% der Websites mit bekannter serverseitiger Sprache PHP. Auf die Gesamtheit aller Websites heruntergebrochen ist der sichere Anker die WordPress-Verbreitung: etwa 42-43% aller Websites laufen auf WordPress - und WordPress läuft auf PHP. In den Traffic-Eliten (Top 1k-100k) ist der PHP-Anteil niedriger, der Long Tail zieht den Schnitt hoch.
- Globale Nutzung: ca. 76-77% (W3Techs, Anteil unter Websites mit bekannter Server-Sprache).
- „Mindestens“-Anteil an allen Websites: ca. 42-43% via WordPress-Anteil (W3Techs).
- Top-Seiten: In den Top 1.000 liegt PHP eher bei ~20-25% (BuiltWith).
- Trend: leichter Rückgang um wenige Punkte über die letzten Jahre, aber sehr hohe Basis bleibt stabil.
- Teams: Viele Produktivsysteme nutzen noch PHP 7.x; 8.x dominiert neuere Deployments (W3Techs, Host-Reports 2025).
Falls du KPIs brauchst, um die Zahl intern zu vertreten: W3Techs (Technologie-Marktanteile), BuiltWith (Technologien in Top-Segmenten), HTTP Archive (Header-/Fingerprint-Sicht) und die Stack Overflow Developer Survey (Einsatz bei Devs) reichen für 360°-Triangulation. Der PHP Marktanteil 2025 wirkt je nach Messmethode unterschiedlich - dazu gleich mehr.
| Quelle / Kennzahl | 2023 | 2024 | 2025 (Stand: Aug/Sep) | Hinweis |
|---|---|---|---|---|
| W3Techs: Anteil PHP (unter Websites mit bekannter Server-Sprache) | ~77% | ~76-77% | ~76-77% | Sehr stabil, leichter Abwärtstrend über Jahre |
| W3Techs: Anteil WordPress (Anteil an allen Websites) | ~43% | ~43% | ~42-43% | WordPress ≈ PHP → harter Unterbau für PHP-Anteil |
| BuiltWith: PHP in Top 1.000 | ~22-26% | ~21-25% | ~20-25% | Eliten bevorzugen auch andere Stacks |
| BuiltWith: PHP in Top 100.000 | ~32-36% | ~31-35% | ~30-35% | Mischzone, viel CMS/E-Commerce |
| W3Techs / Hoster-Reports: Anteil PHP 8.x (innerhalb PHP) | ~50-55% | ~55-60% | ~60-65% | 7.x nimmt ab, 8.2-8.4 dominieren Neu-Deployments |
| Stack Overflow Dev Survey: Devs, die PHP aktiv nutzen | ~21-24% | ~20-23% | ~20-25% | Entwickler-Nutzung ≠ Website-Anteil |
| HTTP Archive: Erkennung via Header/Fingerprints | ~10-15% | ~10-14% | ~10-14% | Unterzählung (CDNs, Header ausgeblendet) |
Quellen: W3Techs (Technologieverbreitung, Stand Aug 2025), BuiltWith (Q3 2025 Snapshots), HTTP Archive (Latest July 2025), Stack Overflow Developer Survey 2024/2025. Zahlen als Bandbreiten angegeben, weil Messmethoden variieren.
Wie diese Zahlen entstehen - und wo man sich leicht vertut
Warum zeigen seriöse Quellen unterschiedliche Werte? Es hängt am Zähler und am Nenner - und daran, wie gut man den Tech-Stack überhaupt erkennt.
- Denominator-Falle: W3Techs misst „unter Websites mit bekannter Server-Sprache“. Das ist ehrlich, aber es ist nicht „alle Websites“. Gute Nachricht: Der WordPress-Anteil an allen Websites liefert eine untere Schranke für PHP.
- Erkennungs-Bias: Viele Seiten verstecken den Stack hinter CDNs, Reverse Proxys oder entfernen „X-Powered-By“. HTTP-Header-basierte Messungen (HTTP Archive) unterschätzen PHP deshalb deutlich.
- Segment-Mix: Der Long Tail (Blogs, KMU-Sites, Vereinsseiten, Nischen-Shops) ist massiv - und dort dominiert WordPress/WooCommerce. In den Top 1.000-10.000 Seiten verschieben sich Anteile durch Microservices, Go/Java/Node, Edge-Rendering und individuelle Stacks.
- Zeitliche Effekte: Migrationen passieren in Wellen (EOL von PHP 7.4, neue LTS-Versionen von Symfony/Laravel, große WP-Releases). Das erzeugt kurzzeitig Sprünge in den Versionsdaten, weniger in den Grundanteilen.
Praktischer Umgang mit Statistiken:
- Nimm W3Techs als Baseline für den Weltmarktanteil, kommuniziere klar den Nenner.
- Verankere den „mindestens“-Anteil mit der WordPress-Zahl (alle Websites).
- Justiere für dein Segment mit BuiltWith: Top x, Land, Branche.
- Nutze HTTP Archive als Gegenprobe, nicht als alleinige Quelle.
Wenn du eigene Properties auswertest: Scanne Deployments via Composer-Locks, Serverpakete, Container-Images oder Application Logs. Header sind zu dünn. In größeren Flotten hilft ein SBOM-Scan (z.B. Syft) oder ein gezielter Grep in Bake-/CI-Skripten.
Warum PHP so präsent bleibt - und wo der Anteil sinkt
Der dickste Anker heißt WordPress. Das Ökosystem ist riesig: Themes, Plugins, Hostings, Agenturnetzwerk, Schulungen. Wer schnell Content online bringen will, landet oft dort. Dazu kommen Drupal, Typo3, Joomla, MediaWiki, Magento/Fork-Landschaft und unzählige Custom-CMS - alles PHP. Selbst wenn Enterprises „Headless“ gehen, hängt oft ein WP/Drupal als Content-Hub dahinter.
Kosten und Verfügbarkeit spielen mit. LAMP-Hosting ist billig, PHP-FPM und OPcache liefern gute Performance out-of-the-box, und praktisch jeder Hoster kann es. Für KMU-Projekte zählt Time-to-Value mehr als ein hipper Stack. Genau dort entsteht die Masse des Webs.
Die sinkenden Bereiche? Neue Greenfield-Backends für hochgradig verteilte Systeme, Streaming, Low-latency-APIs oder heavy ML/Realtime gehen häufiger zu Go, Rust, Java/Kotlin, Node.js oder Python. In den Traffic-Eliten zählt vertikale Skalierung, Observability und Perf-Micro-Optimierung - da punkten Sprachen mit starkem Concurrency- oder JVM-Ökosystem. Und im Jamstack/Edge-Umfeld übernehmen statische Generatoren, SSR über V8-Isolates und Edge Functions Teile, die früher klassische PHP-Server erledigten.
Trotzdem lohnt sich PHP im Jahr 2025 oft noch, weil:
- Business-Problem passt: Content-heavy, SEO-getrieben, Commerce mit großen Plugin-Ökosystemen.
- Team-Skills da sind: Ein funktionierendes PHP-Team schlägt ein hypothetisches Go-Team.
- Gesamtkosten niedrig bleiben: Hosting + Wartung + Community-Support.
- Modernisierung möglich ist: PHP 8.2-8.4, moderne Frameworks (Symfony, Laravel), Static Analysis (PHPStan, Psalm), asynchron (Swoole, RoadRunner) - das ist nicht mehr „nur LAMP von 2008“.
Und ganz nüchtern: Selbst wenn der Anteil langsam fällt, die installierte Basis ist enorm. Unternehmen migrieren nicht im Takt von Twitter, sondern wenn Budgets, Risiken und Nutzen zusammenpassen.
Was du jetzt tun kannst: Entscheidungsbaum, Checklisten & Mini‑FAQ
Du willst eine schnelle Handlungsanleitung statt Debatten? Hier ist sie.
Entscheidungsbaum in 6 Fragen
- Brauchst du in < 4 Wochen ein stabiles, redaktionelles System? → WordPress/Drupal prüfen (PHP).
- Ist dein Geschäftsmodell Commerce-first mit Standard-Shop-Funktionalität? → WooCommerce/Shopware/Magento evaluieren (PHP); Headless ergänzen, wenn nötig.
- Hast du harte Realtime/Streaming-Anforderungen (<50ms Latenz, WebSockets at scale)? → Prüfe Go/Node; PHP geht mit Swoole/RoadRunner, aber Team-Expertise ist Pflicht.
- Muss es streng reguliert (Bank, Medizin) und langfristig planbar sein? → PHP mit Long-Term-Support-Frameworks (Symfony LTS) ist genauso valide wie JVM/Go - entscheide nach Team-Skills, Audits, Vendor-Support.
- Willst du Content-Hub + Frontend-Freiheit? → Headless WordPress/Drupal (PHP) + Frontend (Next/Nuxt/Svelte) kombinieren.
- Hast du ein funktionierendes PHP-System, das Geld verdient? → Nicht plattformwechseln, sondern modernisieren und messen.
Checkliste: Sicher auf PHP 8.4 kommen
- Inventur: Welche Projekte laufen auf 7.x/8.0/8.1? Liste mit Prioritäten (Traffic, Umsatz, Risiko).
- Kompatibilität: CI gegen 8.2/8.3/8.4 laufen lassen; Strict Types und Deprecations sichtbar machen.
- Automatisierte Upgrades: Rector-Regeln für 7.4→8.x; Composer-Abhängigkeiten aktualisieren, Lockfiles prüfen.
- Qualität: PHPStan/Psalm auf Level hochziehen; PHP-CS-Fixer; Unit- und Integrationstests ausbauen.
- Performance: OPcache aktiv, JIT testen (Workload-abhängig), reale Lasttests (k6, JMeter) statt Microbenchmarks.
- Sicherheit: EOL-Zweige schließen, Security-Backports verfolgen, WAF/CDN-Regeln prüfen, Secrets aus Repo entfernen.
- Rollback-Plan: Blue-Green oder Canary-Deploy, Datenbank-Migrationsstrategie (idempotent), Feature Flags.
Checkliste: PHP-Systeme wirtschaftlich betreiben
- Runtime: PHP-FPM richtig dimensionieren (pm, pm.max_children, memory_limit basierend auf Realverbrauch).
- Caching: OPcache, Page-Cache (z.B. WP Rocket), Objekt-Cache (Redis), HTTP-Caching (CDN, Varnish/Nginx).
- Observability: Access/Error Logs zentralisieren, APM (OpenTelemetry/Jaeger, kommerziell nach Bedarf), Budget-Alerts.
- Security-Basics: Least Privilege, regelmäßige Plugin-/Theme-Updates, Dependency-Scanning (Composer Audit), 2FA im Admin.
- Build & Deploy: Reproduzierbare Builds (Composer install --no-dev --prefer-dist), Immutable Images, Healthchecks.
Mini‑FAQ
- Ist PHP „tot“? Nein. Die Daten sprechen dagegen: drei Viertel der bekannten serverseitigen Sites nutzen PHP; WordPress hält den Unterbau stabil. Neue Projekte wählen öfter andere Stacks - das ist normaler Strukturwandel.
- Welche PHP-Version ist 2025 sinnvoll? 8.4 ist der aktuelle Mainstream; 8.5 wird im Herbst erwartet (Release Cycle: jährlich im November). Wähle die jüngste stabile, die dein Framework voll unterstützt.
- Wie lange bekomme ich Security-Fixes? Üblich sind etwa 2 Jahre aktive Unterstützung plus 1 Jahr Security-Fixes pro Minor-Release-Zweig. Plane Migrationen spätestens zum Security-EOL.
- Warum zeigen HTTP-Header so niedrige PHP-Zahlen? Viele Installationen verstecken „X-Powered-By“, hängen hinter CDNs oder liefern nur statische Assets nach außen. Das unterschätzt serverseitige Realitäten.
- Ich starte ein Content-Portal. PHP oder was Neues? Wenn Content und Redaktions-Workflows im Fokus stehen: Starte mit WordPress/Drupal. Brauchst du Speziallogik, ergänze ein separates Service - du musst nicht den CMS-Kern verbiegen.
Pro-Tipps aus der Praxis
- Migriere schrittweise: Zuerst Libraries/frameworks, dann Sprache, dann Performance-Feinschliff. Nicht alles auf einmal.
- „Don’t fight the CMS“: Wenn du WordPress nimmst, nutze es idiomatisch (Custom Post Types, Hooks), statt riesige Plugin-Monolithen zu stapeln.
- Performance-Quickwins: Query-Monitor bei WP, Datenbank-Indizes prüfen, Medien komprimieren, Critical CSS, CDN aktivieren.
- Asynchron, wenn nötig: Queue (RabbitMQ, SQS) für teure Tasks; bei Bedarf Swoole/RoadRunner für Long-running Worker.
- Statische Ausspielung wo möglich: Edge-Cache/Full-Page-Cache senkt Backend-Last dramatisch, besonders bei Content-Sites.
Nächste Schritte nach Persona
- Marketing/Redaktion: Wenn SEO/Content entscheidend ist, pilotiert eine WP-Instanz mit 3-5 Pflichtplugins, testet Redaktionsabläufe, messt Time-to-Publish.
- CTO mit Legacy-PHP: Portfolio-Scan, 7.x-Risiko priorisieren, 8.4-Pilot, CI aufrüsten, dann Rollout in Wellen. Erfolgskriterium: Null-Downtime-Migration.
- Startup-MVP: Wenn Hypothesenvalidierung wichtiger ist als Perfektion: PHP-CMS + Headless-API + modernes Frontend. Wechselt später nur, wenn die Hypothese trägt.
- Data/Architecture: Eigene Tech-Inventory-Stats aufbauen (SBOM, APM-Telemetrie), um Diskussionen mit Zahlen zu führen - nicht mit Bauchgefühl.
Wenn dich also jemand fragt: „Wie viel des Webs nutzt noch PHP?“ - du hast jetzt eine präzise, belastbare Antwort parat - inklusive Einordnung, warum die Zahl so hoch ist und was du damit praktisch anfängst.
