Öffne den Quellcode deiner Seite (Strg+U bzw. Cmd+Option+U). Schau dir den <head>-Bereich an. Siehst du dort Dutzende Codezeilen, die du nicht verstehst? Die meisten davon sind im Jahr 2026 überflüssig: Legacy-Manifeste, Kommentar-Feeds, Emoji-Polyfills und Generator-Meta-Tags aus einer Zeit, in der Windows Live Writer noch relevant war.
Dieses Aufräumen ist keine Kosmetik. Jeder unnötige <link> und jedes Skript kostet Bytes, Parsing-Zeit und manchmal DNS-Lookups. Auf einem WooCommerce-Shop mit vielen Plugins stapeln sich die Tags besonders schnell. Ein sauberer wp_head()-Output macht Debugging leichter und reduziert die Angriffsfläche durch Versions-Leaks.
Referenzen: wp_head(), WordPress Developer Handbook und web.dev zu LCP.
Das Problem: Head-Bloat in WordPress
Eine frische WordPress-Installation mit Standard-Theme liefert im Frontend typischerweise unter anderem:
- RSS-Links für Beiträge, Kategorien, Tags und Kommentare
wlwmanifestfür Windows Live Writer- Really Simple Discovery (
rsd_link) meta name="generator"mit der Core-Version- Emoji-Detection-Skript plus Styles
- Shortlink-Tags (
?p=123) - Adjacent-Post-Links (
rel="prev"/rel="next") - REST- und oEmbed-Discovery-Links
| Element | Nutzen 2026 | Risiko beim Entfernen |
|---|---|---|
| Kommentar-Feed | Sehr gering | Niedrig |
Haupt-Feed /feed/ | Mittel (Newsletter, Reader) | Mittel |
| wlwmanifest / RSD | Legacy | Niedrig |
| Generator-Meta | Keiner (Leak) | Niedrig |
| Emoji-Scripts | Browser nativ | Niedrig |
| REST-Discovery | Hoch bei headless / App | Hoch, wenn du die API nutzt |
| Shortlink | Gering | Niedrig |
Die Tabelle ist die Entscheidungsgrundlage: Nicht alles rausreißen, sondern Legacy und Leakage entfernen, APIs bewusst belassen.
Warum der Kopf aufräumen?
Performance
Vor dem Cleanup siehst du oft 10–20 zusätzliche Tags und ein Emoji-Skript von s.w.org. Nach dem Cleanup sinkt die HTML-Größe, weniger Parser-Arbeit, und in PageSpeed-Traces fehlen die überflüssigen Requests. Der Effekt ist auf mobilen DACH-Verbindungen spürbarer als auf Glasfaser im Büro.
Sicherheit und Informationsleakage
meta name="generator" content="WordPress x.y.z" verrät die Core-Version. Das ist kein Exploit, aber eine Einladung für Scanner, bekannte CVEs gezielt zu prüfen. Dasselbe gilt für Version-Query-Strings an Theme-CSS (style.css?ver=6.x). Generator raus, Versionsstrings an Assets separat härten.
Wartbarkeit
Ein schlanker Head macht Diffs in Staging lesbarer. Wenn ein Plugin plötzlich drei Prefetch-Hints einfügt, fällt das sofort auf. In Audits für deutsche Mittelstandskunden ist „sauberer Head“ oft der erste schnelle Win, bevor man an Redis oder Objekt-Cache geht.
1. RSS für Kommentare und Extra-Feeds
WordPress generiert einen separaten RSS-Feed für jeden Beitrag, jede Kategorie, jeden Tag und Kommentare. Wenn du keine News-Redaktion betreibst, in der Leute Kommentar-Threads per Reader abonnieren, ist das Ressourcenverschwendung und HTML-Rauschen.
// Kommentar-Feed-Links entfernen
add_filter( 'feed_links_show_comments_feed', '__return_false' );
// Extra-Feeds (Kategorien, Tags, Autoren) entfernen
remove_action( 'wp_head', 'feed_links_extra', 3 );
// Nur wenn du den Haupt-Feed wirklich nicht brauchst:
// remove_action( 'wp_head', 'feed_links', 2 );Lass feed_links stehen, wenn Mailchimp, Buttondown oder ein Podcast-Setup den Site-Feed lesen. Kommentar- und Extra-Feeds kannst du in den meisten Unternehmenssites gefahrlos streichen.
2. Windows Live Writer und RSD
Wann hast du zuletzt Windows Live Writer zum Bloggen benutzt? WordPress fügt den Manifest-Link weiterhin hinzu. Really Simple Discovery war für Remote-Publishing gedacht und ist für moderne Workflows irrelevant.
remove_action( 'wp_head', 'wlwmanifest_link' );
remove_action( 'wp_head', 'rsd_link' );Das entfernt typischerweise:
<link rel="wlwmanifest" type="application/wlwmanifest+xml" ...><link rel="EditURI" type="application/rsd+xml" ...>
3. WP Emoji
WordPress lädt JS und CSS, um Zeichen wie :) in Bilder umzuwandeln. Moderne Browser haben eingebaute Emoji-Unterstützung. Das Skript ist eine zusätzliche HTTP-Anfrage plus DNS-Prefetch zu s.w.org.
remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
remove_action( 'wp_print_styles', 'print_emoji_styles' );
remove_action( 'admin_print_scripts', 'print_emoji_detection_script' );
remove_action( 'admin_print_styles', 'print_emoji_styles' );
remove_filter( 'the_content_feed', 'wp_staticize_emoji' );
remove_filter( 'comment_text_rss', 'wp_staticize_emoji' );
remove_filter( 'wp_mail', 'wp_staticize_emoji_for_email' );Wenn dein Content-Team stark mit Emojis in Mails arbeitet und die Darstellung in Outlook kritisch ist, teste die Mail-Filter einzeln. Für Frontend-Performance reichen die wp_head- und Style-Hooks.
4. WordPress-Version (Generator)
Aus Sicherheitsgründen solltest du die Version nicht im Frontend ausgeben.
remove_action( 'wp_head', 'wp_generator' );
add_filter( 'the_generator', '__return_empty_string' );Das leert auch Generator-Tags in Feeds. Es ersetzt keine Updates: Core, Themes und Plugins bleiben gepatcht. Du entfernst nur das Namensschild an der Haustür.
5. Shortlinks und Adjacent Posts
Shortlinks (?p=123) und rel="prev" / rel="next" im Head nutzen moderne Crawler kaum noch sinnvoll. Sie blähen HTML auf.
remove_action( 'wp_head', 'wp_shortlink_wp_head', 10, 0 );
remove_action( 'template_redirect', 'wp_shortlink_header', 11 );
remove_action( 'wp_head', 'adjacent_posts_rel_link_wp_head', 10, 0 );
remove_action( 'wp_head', 'start_post_rel_link', 10, 0 );
remove_action( 'wp_head', 'index_rel_link' );
remove_action( 'wp_head', 'parent_post_rel_link', 10, 0 );6. REST und oEmbed bewusst entscheiden
// Nur entfernen, wenn Frontend keine Discovery braucht:
// remove_action( 'wp_head', 'rest_output_link_wp_head', 10 );
// remove_action( 'wp_head', 'wp_oembed_add_discovery_links' );
// remove_action( 'template_redirect', 'rest_output_link_header', 11 );Headless-Setups, mobile Apps und viele Page-Builder erwarten die REST-Discovery. In einem klassischen Unternehmensblog mit wenig API-Nutzung kannst du die Links entfernen. In einem Headless-WordPress mit Next.js oder Astro als Frontend lässt du sie stehen.
Fertiges Clean-Head-Snippet
Lege das besser als Must-Use-Plugin unter wp-content/mu-plugins/wppoland-clean-head.php ab, nicht nur in functions.php des Parent-Themes.
<?php
/**
* Plugin Name: WPPoland Clean Head
* Description: Entfernt Legacy-Tags aus wp_head.
* Author: wppoland.com
*/
function wppoland_cleanup_head() {
remove_action( 'wp_head', 'rsd_link' );
remove_action( 'wp_head', 'wlwmanifest_link' );
remove_action( 'wp_head', 'wp_generator' );
remove_action( 'wp_head', 'wp_shortlink_wp_head', 10, 0 );
remove_action( 'wp_head', 'adjacent_posts_rel_link_wp_head', 10, 0 );
remove_action( 'wp_head', 'start_post_rel_link', 10, 0 );
remove_action( 'wp_head', 'index_rel_link' );
remove_action( 'wp_head', 'parent_post_rel_link', 10, 0 );
remove_action( 'wp_head', 'feed_links_extra', 3 );
remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
remove_action( 'wp_print_styles', 'print_emoji_styles' );
add_filter( 'feed_links_show_comments_feed', '__return_false' );
add_filter( 'the_generator', '__return_empty_string' );
}
add_action( 'init', 'wppoland_cleanup_head' );Conditional cleanup für spezielle Templates
Manchmal willst du Feeds nur auf der Startseite behalten:
add_action( 'wp', function () {
if ( ! is_front_page() ) {
remove_action( 'wp_head', 'feed_links', 2 );
}
} );Oder Emojis nur im Frontend killen, im Admin aber lassen (falls Redaktion das will). Conditional Logic hält das Snippet wartbar, statt fünf Plugins mit überlappenden Cleanern zu stapeln.
Testen nach dem Deploy
- Inkognito öffnen, Quelltext prüfen: Generator, wlwmanifest, emoji-script weg?
- Network-Tab: kein Request auf
wp-emoji-release.min.js. - Haupt-Feed
/feed/noch erreichbar, falls gewünscht. - Gutenberg-Editor und REST-Calls (z. B. Speichern eines Beitrags) noch grün.
- WooCommerce-Checkout kurz durchklicken, falls Shop aktiv.
In deutschen Projekten mit Strict CSP siehst du nach dem Cleanup oft weniger Console-Noise, weil Emoji-CDN und Prefetch-Hints wegfallen. Das ist ein netter Nebeneffekt, kein Ersatz für eine echte CSP-Policy.
Was du nicht entfernen solltest
viewportund Charset-Meta (Theme)- Canonical und hreflang (SEO-Plugin / Theme)
- Kritische Preloads, die du bewusst gesetzt hast
- Cookie- und Consent-Skripte (rechtlich nötig)
- Schema/
application/ld+json, sofern du es nutzt
Head-Cleanup heißt Legacy raus, nicht „alles unsichtbare löschen“.
Zusammenspiel mit Caching und CDN
Head-Cleanup und Full-Page-Cache verstärken sich. Weniger Tags bedeuten kleinere HTML-Dokumente im Edge-Cache. Nach dem Deploy den HTML-Cache leeren (nicht nur den Browser), sonst prüfst du noch die alte Generator-Zeile. Bei Cloudflare oder einem deutschen Hoster mit Varnish: Cache-Key so belassen, dass eingeloggte Nutzer die Cleanup-Ausgabe nicht mit anonymen Besuchern vermischen.
Plugin-Cleaner und MU-Plugin gleichzeitig sind redundant. Entscheide dich für eine Quelle der Wahrheit. In Audits für Agenturen in Berlin und Hamburg sehen wir oft drei Cleanup-Plugins plus Theme-Code: dann entfernt Plugin A REST-Links, Plugin B fügt sie für oEmbed wieder ein, und niemand weiß, warum der Head wieder wächst.
Redaktionelle Checkliste vor dem Go-live
- Staging mit Produktions-Plugins spiegeln (nicht nur Default-Theme).
- Quelltext der Startseite, eines Beitrags und einer Shop-Seite vergleichen.
- Feed-URL manuell im Reader testen, falls Marketing ihn nutzt.
- Editor speichert einen Gutenberg-Beitrag ohne REST-Fehler.
- Monitoring: HTML-Größe
/vor/nach Cleanup notieren (einfacher Diff im Ticket).
Diese fünf Schritte dauern unter einer Stunde und verhindern die typische „wir haben Emojis gekillt und der Newsletter ist tot“-Regression.
Nächster Schritt
Wenn du Head-Bloat, Third-Party-Skripte und Core Web Vitals zusammen angehen willst, melde dich über Kontakt. Mehr Kontext zur Geschwindigkeit: WordPress-Geschwindigkeitsoptimierung.
