So bereinigen Sie den WordPress-Header (RSS, Emojis, Shortlinks entfernen)

Öffnen Sie den Quellcode Ihrer Website (Strg+U auf Windows, Cmd+Option+U auf dem Mac). Scrollen Sie zum <head>-Bereich. Zwischen charset, Viewport und dem Theme-CSS liegen oft ein Dutzend <link>-, <meta>- und <script>-Zeilen, die kein Redakteur bestellt hat: Kommentar-Feeds, ein RSD-Link, ein Emoji-Settings-Block, Shortlinks mit ?p=123 und ein Generator-Meta-Tag mit der Core-Version.

Diese Artefakte kommen aus wp_head(). Core hängt dort Callbacks ein. Mit remove_action() nehmen Sie gezielt wieder heraus, was Ihr Projekt nicht braucht. Der Beitrag dokumentiert jedes typische Artefakt, eine sichere Entfernungsliste, geprüft gegen wp-includes/default-filters.php in WordPress 7.1.3, Dinge die Sie stehen lassen sollten, den Unterschied zwischen Emoji-Skript und Emoji-Styles, die Beziehung von Shortlink zu Canonical, die HTTP-Header sowie die Entscheidung zwischen Must-Use-Plugin und Theme-functions.php.

Bezug zur Praxis in DACH: Auf einem WooCommerce-Shop mit Elementor und zehn Plugins wuchs der <head> einer Mode-Marke aus Stuttgart auf über 40 Tags. Nach dem Cleanup lagen noch Theme-CSS, Favicons, Canonical und die restlichen Plugin-Assets. Der Lighthouse-LCP-Wert verbesserte sich nicht dramatisch, aber der HTML-Payload schrumpfte, und Debugging im Network-Panel wurde wieder lesbar. Genau das ist der Job: weniger Rauschen, nicht Marketing-Zahlen.

#Welche Tags gibt wp_head im WordPress-Header aus

wp_head ist ein Action-Hook. Klassische Themes rufen ihn in header.php über wp_head() auf, Block-Themes bekommen den Aufruf aus dem Template-Canvas von Core. Core und Plugins registrieren Callbacks mit Prioritäten. Entfernen Sie einen Callback, verschwindet nur dessen Ausgabe, der Hook selbst bleibt.

Typische Core-Callbacks im Frontend-<head> von WordPress 7.1, mit der Priorität aus default-filters.php:

Zwei Zeilen, die ältere Snippets noch erwähnen, fehlen in dieser Liste. wlwmanifest_link ist seit WordPress 6.3 veraltet und nicht mehr eingehängt, und adjacent_posts_rel_link_wp_head nutzt Core seit 5.6 nicht mehr. Die Emoji-Styles sind in 6.4 von print_emoji_styles zu wp_enqueue_emoji_styles gewandert. Jede dieser Änderungen ist unten beschrieben.

Die Tabelle ersetzt Blindflug. Vor dem ersten remove_action lohnt ein Blick in den Quelltext einer Staging-Seite und ein Abgleich mit dieser Liste.

#WordPress-Header mit remove_action bereinigen

Die folgende Funktion ist der Kern. Sie hängt an init, damit die Callbacks, die Sie entfernen, bereits registriert sind. Prioritäten müssen zu den Original-Registrierungen passen: feed_links läuft mit Priorität 2, feed_links_extra mit 3, das Emoji-Detection-Skript mit 7. remove_action() nimmt drei Parameter (Hook, Callback, Priorität); das vierte Argument, das viele Snippets mitgeben, wird ignoriert.

/**
 * WordPress head-Bereich bereinigen.
 * Entfernt Legacy-Links, Generator, Emoji-Assets und Shortlinks.
 */
function wppoland_cleanup_head() {
	// RSS: Haupt- und Extra-Feeds aus dem Head nehmen.
	remove_action( 'wp_head', 'feed_links', 2 );
	remove_action( 'wp_head', 'feed_links_extra', 3 );

	// Really Simple Discovery (EditURI-Link).
	remove_action( 'wp_head', 'rsd_link' );

	// Generator-Meta und Generator in Feeds.
	remove_action( 'wp_head', 'wp_generator' );
	add_filter( 'the_generator', '__return_empty_string' );

	// Emoji: Detection-Skript, Styles, Feed- und Mail-Umwandlung.
	remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
	remove_action( 'admin_print_scripts', 'print_emoji_detection_script' );
	remove_action( 'embed_head', 'print_emoji_detection_script' );
	remove_action( 'wp_print_styles', 'print_emoji_styles' );
	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' );

	// Shortlink im HTML-Head und im HTTP-Link-Header.
	remove_action( 'wp_head', 'wp_shortlink_wp_head', 10 );
	remove_action( 'template_redirect', 'wp_shortlink_header', 11 );
}
add_action( 'init', 'wppoland_cleanup_head' );

Hinweise zur Anwendung:

• Wenn Newsletter-Tools oder externe Aggregatoren Ihren Haupt-Feed lesen, lassen Sie feed_links stehen und schalten nur die Feeds ab, die Sie nicht brauchen, mit den Filtern aus dem RSS-Abschnitt weiter unten.
• rsd_link können Sie auf praktisch jeder öffentlichen Site streichen. Remote-Publishing über XML-RPC ist ohnehin ein eigenes Risikothema.
• the_generator greift auch in Feed-XML. Leerer String verhindert Versionsnummern dort ebenfalls.

#Welche remove_action-Zeilen unter WordPress 7 nichts bewirken

Cleanup-Snippets aus Foren enthalten Zeilen, die in Core auf nichts mehr treffen. Sie legen keine Site lahm, weil remove_action() einfach false zurückgibt, wenn der Callback nicht registriert ist. Sie führen aber den nächsten Entwickler in die Irre, der glaubt, die Zeile tue etwas.

• remove_action( 'wp_head', 'wlwmanifest_link' ): Der Manifest-Link für Windows Live Writer ist seit WordPress 6.3 veraltet. Die Funktion löst nur noch einen Deprecation-Hinweis aus, und Core hängt sie nicht mehr ein. Behalten Sie die Zeile nur, wenn Sie noch Sites unter 6.3 betreuen.
• remove_action( 'wp_head', 'adjacent_posts_rel_link_wp_head', 10 ): Die Funktion existiert noch, aber ihr eigener Docblock sagt, dass Core sie seit 5.6 nicht mehr nutzt. Sehen Sie rel="prev" und rel="next" auf Einzelbeiträgen, setzt sie ein Theme oder Plugin.
• start_post_rel_link, index_rel_link, parent_post_rel_link: veraltet seit WordPress 3.3. Keine aktuelle Installation hängt sie ein.
• remove_filter( 'wp_resource_hints', 'wp_dependencies_emoji_styles' ): Diese Funktion gibt es in Core nicht. Der DNS-Prefetch zu s.w.org, den die Zeile stoppen sollte, wurde in WordPress 6.1 aus wp_resource_hints() entfernt.
• add_filter( 'rest_enabled', '__return_false' ): Der Filter ist seit 4.7 veraltet. Core verweist stattdessen auf rest_authentication_errors, und die REST-API lässt sich auf diesem Weg nicht mehr abschalten.

Diese Zeilen zu streichen macht die Datei kürzer und das Review leichter. Referenz für den Abgleich ist der Quelltext von default-filters.php in 7.1.3.

#Welche wp_head-Einträge man nicht entfernen sollte

Cleanup endet dort, wo Core und Editor noch funktionieren müssen. Vier Klassen gehören in die Schonliste.

#REST-API-Discovery

rest_output_link_wp_head schreibt einen Link auf /wp-json/, und rest_output_link_header sendet denselben Link als HTTP-Header. Gutenberg, der Site-Editor, viele Formular-Plugins und Headless-Frontends brauchen die REST-API. Entfernen Sie den Discovery-Link pauschal, bricht nichts sofort, aber Clients finden den Endpunkt schwerer, und Sie lösen ein Scheinproblem. Wer REST wirklich absichern will, beschränkt Authentifizierung und Routen, statt den Link zu verstecken.

#Theme- und Plugin-CSS

Stylesheets kommen über wp_enqueue_style und landen über wp_print_styles (Priorität 8) im Head. Wer wp_head komplett leert oder pauschal alle Styles killt, zerstört das Layout. Cleanup zielt auf Core-Legacy-Callbacks, nicht auf wp_enqueue_*. Dasselbe gilt für wp_enqueue_script von Theme und Plugins: nur gezielt deregistrieren, wenn Sie die Abhängigkeit kennen.

#Canonical, Open Graph und Meta-Tags

rel_canonical bleibt. Ohne Canonical riskieren Sie Duplicate-Content-Signale bei Varianten mit Query-Strings, Pagination oder Tracking-Parametern. Open-Graph- und Twitter-Tags von SEO-Plugins lassen Sie ebenfalls unangetastet, sofern das Plugin sie sauber setzt.

#Titel, Robots, Icons und eigenes CSS

_wp_render_title_tag und wp_robots laufen mit Priorität 1 und geben <title> und das Robots-Meta aus. wp_site_icon schreibt mit Priorität 99 das Favicon, wp_custom_css_cb mit 101 das zusätzliche CSS aus dem Customizer. Nichts davon ist Ballast.

Kurz: Extra-Feeds, RSD, Generator, Emoji-Assets und Shortlinks sind Kandidaten. REST, CSS, Canonical, Titel, Robots und Icons sind Infrastruktur.

#WordPress-Emojis ohne Plugin deaktivieren

Viele Snippets entfernen nur das Detection-Skript und vergessen die Styles, oder umgekehrt. Core trennt die Pfade bewusst, und beide haben sich in den letzten Versionen geändert.

print_emoji_detection_script hängt an wp_head (Priorität 7) und an admin_print_scripts. Seit WordPress 6.9 schreibt es nichts mehr inline in den Head. Es plant _print_emoji_detection_script auf wp_print_footer_scripts ein, und diese Funktion gibt vor </body> einen JSON-Settings-Block (id="wp-emoji-settings") und den Emoji-Loader als type="module"-Skript aus. Der Loader prüft, ob der Browser Emojis nativ zeichnet, und legt das Ergebnis in sessionStorage ab. Nur wenn der Test scheitert, lädt er wp-emoji-release.min.js nach, das Emojis durch Bilder von s.w.org ersetzt. Auf einem aktuellen Browser kosten also die Inline-Settings und der Loader-Code (die unminifizierte Loader-Quelle hat rund 13 KB), nicht ein kompletter Polyfill-Download.

Die Styles gingen einen anderen Weg. print_emoji_styles ist seit 6.4 veraltet und wurde durch wp_enqueue_emoji_styles ersetzt, das einen Inline-Style unter dem Handle wp-emoji-styles einreiht. Aus Kompatibilitätsgründen hängt Core print_emoji_styles weiterhin an wp_print_styles, und die neue Funktion bricht ab, wenn dieser Hook entfernt wurde. Deshalb wirkt remove_action( 'wp_print_styles', 'print_emoji_styles' ) auch unter 7.1. Gleichwertig und direkter ist remove_action( 'wp_enqueue_scripts', 'wp_enqueue_emoji_styles' ).

Zusätzliche Filter (wp_staticize_emoji auf the_content_feed und comment_text_rss, wp_staticize_emoji_for_email auf wp_mail) wandeln Emojis in Feeds und Mails in Bilder um. Für redaktionelle Sites ohne Emoji-lastige Newsletter können Sie die Filter mitentfernen. Ein Magazin in Hamburg, das in Slack und Mail viel mit Emojis arbeitet, lässt die Mail-Filter lieber stehen und räumt nur Frontend-Head auf.

Admin-Hooks mitentfernen: Sonst bleibt der Ballast im Dashboard. Frontend-only Cleanup spart dem Besucher Bytes, nicht dem Redakteur beim Speichern.

#WordPress-Emoji-Bilder selbst hosten

Entfernen ist eine Option. Wer Emoji-Unterstützung für alte Browser behalten, aber keine Requests an eine Fremddomain schicken will, biegt die Bild-URLs auf den eigenen Server um. Core bietet dafür zwei Filter: emoji_url für den PNG-Satz und emoji_svg_url für den SVG-Satz. In WordPress 7.1 lauten die Standardwerte https://s.w.org/images/core/emoji/17.0.2/72x72/ und https://s.w.org/images/core/emoji/17.0.2/svg/.

add_filter( 'emoji_url', function () {
	return content_url( '/emoji/17.0.2/72x72/' );
} );
add_filter( 'emoji_svg_url', function () {
	return content_url( '/emoji/17.0.2/svg/' );
} );

Das Versionssegment im Pfad ändert sich, wenn Core seinen Emoji-Satz aktualisiert. Eine selbst gehostete Kopie muss also mit Major-Releases nachgezogen werden. wp_staticize_emoji nutzt für Feeds denselben Filter emoji_url, eine Änderung deckt also beide Stellen ab.

#WordPress-Shortlink entfernen, Canonical behalten

wp_shortlink_wp_head schreibt <link rel="shortlink" href="https://example.com/?p=42" />. Zusätzlich läuft wp_shortlink_header auf template_redirect mit Priorität 11 und setzt einen HTTP-Header Link: <...>; rel=shortlink. Beide sind Komfort für alte Sharing-Tools. Suchmaschinen folgen dem Canonical, nicht dem Shortlink.

rel_canonical zeigt auf die kanonische Permalink-URL. Shortlink und Canonical widersprechen sich nicht direkt, aber zwei URL-Signale für dieselbe Ressource erzeugen Rauschen. Shortlink weg, Canonical bleibt: klare Präferenz für den Pretty-Permalink.

Wenn ein Redirect-Plugin oder ein CDN Short-URLs pflegt, prüfen Sie nach dem Cleanup einmal die Response-Header in den DevTools (Network, dann der Dokument-Request, dann Response Headers). Der Link-Header mit rel=shortlink sollte verschwunden sein. Canonical im HTML bleibt sichtbar.

#X-Pingback und andere WordPress-HTTP-Header entfernen

Der <head> ist nur die Hälfte dessen, was WordPress ausliefert. Drei Response-Header kommen aus Core.

• X-Pingback: Seit WordPress 4.4 setzt WP::send_headers() ihn nur noch auf Einzelansichten von Beiträgen, die Pings annehmen. Er zeigt auf xmlrpc.php.
• Link: <...>; rel=shortlink: kommt von wp_shortlink_header und verschwindet mit dem Shortlink-Code oben.
• Link: <...>; rel="https://api.w.org/": kommt von rest_output_link_header. Behalten, aus denselben Gründen wie den REST-Link im HTML.

Alle Header, die WP::send_headers() sammelt, laufen durch den Filter wp_headers (seit 2.8). Dort lässt sich X-Pingback entfernen:

add_filter( 'wp_headers', function ( $headers ) {
	unset( $headers['X-Pingback'] );
	return $headers;
} );

Sind Pings für einen Beitrag geschlossen, wird der Header gar nicht erst gesendet. Ein <link rel="pingback">-Tag hängt Core nicht an wp_head. Taucht er im Quelltext auf, stammt er aus der header.php des Themes.

#Gehört der Header-Cleanup ins mu-plugin oder in die functions.php

Beide Orte funktionieren. Die Betriebsfrage ist Überlebensdauer.

functions.php im Child-Theme ist schnell: SFTP oder Theme-Editor, speichern, fertig. Nachteil: Theme-Wechsel oder ein neues Child löscht die Logik. Agenturen, die Kunden-Themes austauschen, verlieren den Cleanup still.

Ein Must-Use-Plugin unter wp-content/mu-plugins/wppoland-clean-head.php lädt WordPress automatisch, ohne Aktivierungsklick. Theme-Wechsel ändert nichts. Deployment per Git oder rsync bleibt einfach, weil die Datei außerhalb des Themes liegt. Auf Hostern wie Raidboxes oder All-Inkl legen Sie den Ordner einmal an und versionieren die Datei mit dem Rest des Projekts.

Empfehlung für Produktionssites: mu-plugin. Empfehlung für Einmal-Experimente auf Staging: Child-Theme ist akzeptabel, solange Sie die Funktion später migrieren. Vermeiden Sie Parent-Theme-Edits; Updates überschreiben sie.

Beispiel-Gerüst für ein mu-plugin:

<?php
/**
 * Plugin Name: WPPoland Clean Head
 * Description: Entfernt Legacy-wp_head-Artefakte.
 * Author: wppoland.com
 * Version: 1.0.0
 */

if ( ! defined( 'ABSPATH' ) ) {
	exit;
}

require_once __DIR__ . '/includes/cleanup-head.php';

Die eigentliche wppoland_cleanup_head-Funktion liegt dann in includes/cleanup-head.php. So bleibt die Bootstrap-Datei kurz und testbar. Schreiben Sie neben jede Entfernung einen Kommentar, warum sie dort steht:

// Emoji-Detection entfernen: alle unterstützten Browser rendern Emojis nativ.
remove_action( 'wp_head', 'print_emoji_detection_script', 7 );

#wp_head nur im Frontend oder für Headless bereinigen

Manche Entfernungen gehören nur in bestimmte Kontexte. Das Beispiel behält den REST-Link, wenn eine eigene Konstante die Site als headless markiert.

function wppoland_conditional_head_cleanup() {
	// WPPOLAND_HEADLESS ist eine Projektkonstante aus der wp-config.php.
	if ( ! defined( 'WPPOLAND_HEADLESS' ) || ! WPPOLAND_HEADLESS ) {
		remove_action( 'wp_head', 'rest_output_link_wp_head', 10 );
	}
}
add_action( 'init', 'wppoland_conditional_head_cleanup' );

#Jeden Teil des Cleanups schaltbar machen

Auf Sites, deren Integrationen sich zwischen Umgebungen unterscheiden, kapseln Sie jede Gruppe von Entfernungen in eine Konstante aus der wp-config.php. Eine Gruppe läuft, solange ihre Konstante nicht als false definiert ist:

/**
 * Konfiguration in der wp-config.php, zum Beispiel:
 * define( 'WPPCLEANUP_FEED_LINKS', false );
 */
function wppoland_advanced_cleanup_head() {
	if ( ! defined( 'WPPCLEANUP_FEED_LINKS' ) || WPPCLEANUP_FEED_LINKS ) {
		remove_action( 'wp_head', 'feed_links', 2 );
		remove_action( 'wp_head', 'feed_links_extra', 3 );
	}
	if ( ! defined( 'WPPCLEANUP_RSD' ) || WPPCLEANUP_RSD ) {
		remove_action( 'wp_head', 'rsd_link' );
	}
	if ( ! defined( 'WPPCLEANUP_GENERATOR' ) || WPPCLEANUP_GENERATOR ) {
		remove_action( 'wp_head', 'wp_generator' );
		add_filter( 'the_generator', '__return_empty_string' );
	}
	if ( ! defined( 'WPPCLEANUP_EMOJIS' ) || WPPCLEANUP_EMOJIS ) {
		remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
		remove_action( 'wp_print_styles', 'print_emoji_styles' );
		remove_filter( 'wp_mail', 'wp_staticize_emoji_for_email' );
	}
	if ( ! defined( 'WPPCLEANUP_SHORTLINKS' ) || WPPCLEANUP_SHORTLINKS ) {
		remove_action( 'wp_head', 'wp_shortlink_wp_head', 10 );
		remove_action( 'template_redirect', 'wp_shortlink_header', 11 );
	}
}
add_action( 'init', 'wppoland_advanced_cleanup_head' );

Staging kann dann die Feeds behalten, während die Produktion sie entfernt, ohne zwei Versionen der Plugin-Datei.

#Wie man den bereinigten Header im Quelltext prüft

Nach dem Deploy öffnen Sie eine öffentliche URL im Inkognito-Fenster und prüfen drei Ebenen.

1. Seitenquelltext (Strg+U): Suchen Sie nach EditURI, emoji, shortlink, generator und alternate. Seit WordPress 6.9 stehen die Emoji-Settings vor </body>, durchsuchen Sie also das ganze Dokument, nicht nur den Head. Die Legacy-Treffer sollten fehlen. Canonical, Stylesheets und notwendige Plugin-Tags bleiben.
2. DevTools Network: Filtern Sie nach s.w.org und wp-emoji. Nach Emoji-Cleanup sollte kein Request mehr erscheinen. Zählen Sie Head-Requests vor und nach dem Change auf derselben URL.
3. Response-Header: Kein Link-Header mit rel=shortlink und kein X-Pingback, wenn Sie ihn entfernt haben. Manche Security-Plugins setzen eigene Header; die bleiben unberührt.

Checkliste für den Abnahme-Lauf:

• Staging und Produktion getrennt testen; Object-Cache und Page-Cache leeren.
• Eine Beitragsseite, eine Archivseite und die Startseite prüfen (Extra-Feeds verhalten sich unterschiedlich).
• WooCommerce-Produktseite extra checken: Plugins hängen dort oft zusätzliche Tags ein, die nicht von diesem Snippet kommen.
• Gutenberg-Editor einmal öffnen und speichern: REST muss antworten.
• Optional PageSpeed oder WebPageTest: HTML-Bytes und Third-Party-Domains vergleichen. Erwarten Sie keine Wunder-Scores; erwarten Sie weniger Rauschen.

Ein Fall aus der Praxis: Nach dem Cleanup auf einer Verbandsseite in München zeigte der Quelltext weiterhin emoji-release.min.js. Ursache war nicht Core, sondern ein Social-Plugin, das denselben CDN-Pfad nachlud. remove_action auf Core-Hooks reicht dann nicht; das Plugin muss konfiguriert oder ersetzt werden. Deshalb immer den sichtbaren Quelltext lesen, nicht nur dem Snippet vertrauen.

#WordPress RSS-Feed-Links aus dem Head entfernen

RSS ist nicht tot. Podcasts, Newsletter-Importe und Monitoring-Tools lesen /feed/ weiterhin. Kommentar-Feeds und taxonomiespezifische Feeds dagegen erzeugen selten Traffic und blähen den Head auf Archiven auf.

Pragmatische Stufen:

1. Nur Kommentar-Feed aus (feed_links_show_comments_feed liefert false). Haupt-Feed bleibt.
2. Extra-Feeds aus (feed_links_extra entfernen). Kategorien und Tags verlieren Autodiscovery im Head; die Feed-URLs existieren weiter, falls jemand die URL kennt.
3. Alle Feed-Links aus dem Head (feed_links und feed_links_extra). Die Endpunkte bleiben erreichbar, nur Autodiscovery entfällt.

Stufe 1 oder 2 reicht für die meisten Unternehmenssites. Stufe 3 nur, wenn wirklich niemand den Feed abonniert und Sie das bewusst wollen.

feed_links() gibt nichts aus, solange das Theme nicht add_theme_support( 'automatic-feed-links' ) erklärt. Zeigt eine Site überhaupt keine Feed-Links, prüfen Sie zuerst das Theme, bevor Sie Entfernungscode schreiben.

#Haupt-Feed behalten und nur einzelne Extra-Feeds abschalten

feed_links_extra zu entfernen ist alles oder nichts. Core bietet feinere Schalter. feed_links_show_posts_feed und feed_links_show_comments_feed gibt es seit WordPress 4.4. WordPress 6.1 brachte einen Filter pro Extra-Feed-Typ: feed_links_extra_show_post_comments_feed, feed_links_extra_show_post_type_archive_feed, feed_links_extra_show_category_feed, feed_links_extra_show_tag_feed, feed_links_extra_show_tax_feed, feed_links_extra_show_author_feed und feed_links_extra_show_search_feed. Seit 6.7 filtert feed_links_args Trennzeichen und Titel der Feed-Links.

// Posts-Feed und Kategorie-Feeds behalten, übrige Extras abschalten.
add_filter( 'feed_links_show_comments_feed', '__return_false' );
add_filter( 'feed_links_extra_show_tag_feed', '__return_false' );
add_filter( 'feed_links_extra_show_author_feed', '__return_false' );
add_filter( 'feed_links_extra_show_search_feed', '__return_false' );

feed_links_extra_show_post_comments_feed übernimmt als Standardwert das Ergebnis von feed_links_show_comments_feed. Wer den globalen Kommentar-Feed abschaltet, entfernt damit auch den Link zum Kommentar-Feed des einzelnen Beitrags, außer Sie geben dafür separat true zurück. Die Parameter stehen im Referenzeintrag zu feed_links_extra_show_category_feed.

#WordPress-Version im Quelltext verstecken

wp_generator schreibt die Core-Version ins HTML. Das ist kein Einbruch, aber Scanner priorisieren Versionen mit bekannten CVEs. Entfernen Sie den Meta-Tag und leeren Sie the_generator. Die Version steht auch an anderen Stellen:

1. Query-Strings an Assets: Core-Styles und -Skripte tragen ?ver= mit der Core-Version, zum Beispiel an wp-emoji-release.min.js.
2. readme.html: Die Datei liegt im WordPress-Wurzelverzeichnis (/readme.html), nicht in wp-content, und jedes Core-Update stellt sie wieder her. Sperren Sie sie auf Webserver-Ebene, wenn Ihnen das wichtig ist.
3. Plugins: Viele Plugins schreiben ihre eigene Version in Kommentare oder Asset-URLs.

Head-Cleanup allein ist kein Security-Programm; er reduziert ein Signal. Die CVEs, nach denen ein Scanner sucht, schließen Updates von Core und Plugins.

#Den ver-Parameter aus CSS- und JS-URLs entfernen

Die Filter style_loader_src und script_loader_src bekommen jede eingereihte Asset-URL, dort lässt sich das Argument ver streichen:

function wppoland_remove_version_from_assets( $src ) {
	if ( $src && strpos( $src, 'ver=' ) !== false ) {
		$src = remove_query_arg( 'ver', $src );
	}
	return $src;
}
add_filter( 'style_loader_src', 'wppoland_remove_version_from_assets', 9999 );
add_filter( 'script_loader_src', 'wppoland_remove_version_from_assets', 9999 );

Der Parameter sorgt nach einem Update auch dafür, dass Browser- und CDN-Caches die neue Datei holen. Ohne ihn kann eine geänderte Datei unter derselben URL aus dem Cache kommen. Behalten Sie diesen Filter also nur, wenn Ihr Deploy oder CDN die Cache-Invalidierung auf anderem Weg erledigt.

#Bringen rel prev und next noch SEO-Vorteile

rel="prev" und rel="next" zwischen Einzelbeiträgen halfen früher bei Serialisierung. Für Einzelbeiträge gibt Core sie seit 5.6 nicht mehr aus, auf einer aktuellen Site kommen sie also vom Theme oder einem SEO-Plugin. Für moderne Crawler ist der Effekt vernachlässigbar. Auf Magazin-Sites mit langer Artikelkette können Sie die Links behalten; auf Service- und Shop-Sites entfernen Sie sie ohne Reue in dem Plugin, das sie setzt. Interne Verlinkung im Content und sinnvolle Sitemaps wiegen schwerer.

#Header-Cleanup mit WP Rocket und Page-Cache

Autoptimize, FlyingPress, WP Rocket und ähnliche Tools ändern Reihenfolge und Kombination von Assets. Ihr remove_action-Snippet sollte vor dem HTML-Cache greifen, also in PHP, nicht als nachträglicher String-Replace im Optimizer. Wenn ein Optimizer Emoji-Skripte erneut injiziert oder Third-Party-Domains freigibt, prüfen Sie dessen Einstellungen.

Object-Cache speichert keine wp_head-Ausgabe so, dass remove_action wirkungslos würde. Page-Cache schon: alte HTML-Kopien behalten den Ballast, bis der Cache leer ist. Nach dem Deploy ist Cache purge Pflicht.

#Warum remove_action in wp_head nicht greift

Falsche Priorität: remove_action( 'wp_head', 'feed_links' ) ohne Priorität 2 trifft den Callback nicht. Core registriert mit Priorität; Ihre Entfernung muss dieselbe Zahl tragen.

Zu früher Hook: Wenn Sie remove_action direkt in der Plugin-Datei ohne init ausführen, sind manche Callbacks noch nicht registriert. init oder wp_loaded sind sicherer als Top-Level-Code.

Parent-Theme überschrieben: Update kommt, Cleanup weg. Child oder mu-plugin nutzen.

REST mitentfernt aus Copy-Paste-Listen im Netz: Editor bricht oder Headless-Apps finden /wp-json/ nicht. Listen aus Foren von 2014 ungeprüft übernehmen ist riskant; gegen die Tabelle in diesem Beitrag halten.

Veraltete Callback-Namen: Die Zeile zielt auf eine Funktion, die Core nicht mehr einhängt, wie im Abschnitt zu wirkungslosen Zeilen aufgelistet. Das Tag, das Sie loswerden wollen, kommt dann von woanders.

Nur Frontend getestet: Admin behält die Emoji-Assets. Das stört Besucher nicht, aber Redakteure auf langsamen VPN-Strecken schon. Admin-Hooks mitnehmen, wenn das Team zustimmt.

#Zusammenfassung

wp_head sammelt Core-, Theme- und Plugin-Ausgabe. Legacy-Artefakte (RSD, Extra-Feeds, Generator, Emoji-Assets, Shortlink) dürfen Sie gezielt mit remove_action und wenigen Filtern streichen. REST-Discovery, enqueued CSS/JS, Titel, Robots, Icons und Canonical bleiben. Emoji-Skript und Emoji-Styles getrennt behandeln, und wissen, dass das Skript seit 6.9 im Footer steht. Shortlink im HTML und im HTTP-Header entfernen, Canonical behalten. Die Zeilen für wlwmanifest_link und die Adjacent-Post-Links auf aktuellen Versionen streichen. Die Logik gehört ins mu-plugin, nicht ins Parent-Theme. Verifikation läuft über Quelltextsuche, Network-Panel und Response-Header, plus Cache-Purge.

Referenzen aus dem Developer Handbook: wp_head, remove_action, feed_links, feed_links_extra, print_emoji_detection_script, wp_enqueue_emoji_styles, wp_shortlink_wp_head, wp_shortlink_header, wp_generator, rsd_link, wlwmanifest_link, rel_canonical, wp_headers.

Brauchen Sie Hilfe bei der Umsetzung auf Staging und Produktion? Als WordPress-Spezialist bereinige ich wp_head projektbezogen und prüfe den Quelltext mit Ihnen gemeinsam.