Como limpiar el header de WordPress (eliminar RSS, emojis, shortlinks)

Abre el código fuente de tu sitio (Ctrl+U en Windows, Cmd+Option+U en un Mac) y baje hasta la sección <head>. Entre charset, el viewport y el CSS del tema suele haber una docena de líneas <link>, <meta> y <script> que nadie del equipo editorial ha pedido: feeds de comentarios, un enlace de descubrimiento RSD, un bloque de ajustes de emoji, un shortlink con ?p=123 y una meta etiqueta generator con la versión del núcleo.

Estos artefactos salen de wp_head(). El núcleo engancha callbacks a ese hook, y remove_action() retira lo que tu proyecto no necesita. Esta guía recorre cada artefacto habitual, una lista segura de eliminaciones comprobada con wp-includes/default-filters.php de WordPress 7.1.3, lo que conviene dejar en paz, la diferencia entre el script y los estilos de emoji, el shortlink frente al canonical, las cabeceras a nivel HTTP y la elección entre un plugin must-use y el functions.php del tema.

El objetivo es reducir el ruido en el HTML y en el panel de red. Quitar estas etiquetas no moverá por sí solo una puntuación de Lighthouse, pero vuelve legible el documento y cierra algunas pequeñas fugas de información. Si lo que buscas es el tiempo de carga, consulta la guía de optimización de velocidad WordPress.

#Qué imprime wp_head en el header de WordPress

wp_head es un action hook. Los temas clásicos llaman a wp_head() en header.php; los temas de bloques reciben la llamada desde el template canvas del núcleo. El núcleo y los plugins registran callbacks en él con prioridades. Eliminar un callback elimina solo la salida de ese callback; el hook sigue ejecutándose.

Callbacks habituales del núcleo en el <head> del front end de WordPress 7.1, con la prioridad de default-filters.php:

Faltan en esta lista dos filas que los fragmentos antiguos aún mencionan. wlwmanifest_link quedó obsoleta en WordPress 6.3 y ya no está enganchada, y el núcleo no usa adjacent_posts_rel_link_wp_head desde 5.6. Los estilos de emoji pasaron de print_emoji_styles a wp_enqueue_emoji_styles en 6.4. Cada cambio se explica más abajo.

La tabla sustituye a las conjeturas. Antes del primer remove_action, revisa el código fuente de una página de staging y compárelo con esta lista.

#Cómo limpiar el header de WordPress con remove_action

La función siguiente es el núcleo de la limpieza. Se ejecuta en init, de modo que los callbacks que elimina ya están registrados. La prioridad que pases debe coincidir con el registro original: feed_links se registra con 2, feed_links_extra con 3 y el script de detección de emoji con 7. remove_action() acepta tres parámetros (hook, callback, prioridad); el cuarto argumento que pasan muchos fragmentos se ignora.

/**
 * Limpia la sección head de WordPress.
 * Elimina enlaces legacy, el generator, los recursos de emoji y los shortlinks.
 */
function wppoland_cleanup_head() {
	// RSS: enlaces del feed principal y de los feeds extra fuera del head.
	remove_action( 'wp_head', 'feed_links', 2 );
	remove_action( 'wp_head', 'feed_links_extra', 3 );

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

	// Meta etiqueta generator y el generator en los feeds.
	remove_action( 'wp_head', 'wp_generator' );
	add_filter( 'the_generator', '__return_empty_string' );

	// Emoji: script de detección, estilos, conversión en feeds y correo.
	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 en el head HTML y en la cabecera HTTP Link.
	remove_action( 'wp_head', 'wp_shortlink_wp_head', 10 );
	remove_action( 'template_redirect', 'wp_shortlink_header', 11 );
}
add_action( 'init', 'wppoland_cleanup_head' );

Notas de uso:

• Si herramientas de newsletter o agregadores externos leen tu feed principal, conserva feed_links y desactiva solo los feeds que no necesites con los filtros descritos en la sección de RSS más abajo.
• rsd_link puede eliminarse en prácticamente cualquier sitio público. La publicación remota por XML-RPC es, de todos modos, un tema de riesgo aparte.
• the_generator también se aplica al XML de los feeds. Una cadena vacía elimina allí también el número de versión.

#Qué líneas de remove_action no hacen nada en WordPress 7

Los fragmentos de limpieza copiados de foros arrastran líneas que ya no coinciden con nada del núcleo. No rompen el sitio, porque remove_action() simplemente devuelve false cuando el callback no está registrado. Pero inducen a error al siguiente desarrollador, que cree que la línea hace algo.

• remove_action( 'wp_head', 'wlwmanifest_link' ): el enlace al manifiesto de Windows Live Writer quedó obsoleto en WordPress 6.3. La función ahora solo lanza un aviso de obsolescencia y el núcleo ya no la engancha. Mantén la línea solo si todavía das soporte a sitios por debajo de 6.3.
• remove_action( 'wp_head', 'adjacent_posts_rel_link_wp_head', 10 ): la función sigue existiendo, pero su propio docblock indica que el núcleo no la usa desde 5.6. Si ves rel="prev" y rel="next" en entradas individuales, los añade un tema o un plugin.
• start_post_rel_link, index_rel_link, parent_post_rel_link: obsoletas desde WordPress 3.3. Ninguna instalación moderna las engancha.
• remove_filter( 'wp_resource_hints', 'wp_dependencies_emoji_styles' ): esa función no existe en el núcleo. El DNS prefetch a s.w.org que esta línea pretendía evitar se eliminó de wp_resource_hints() en WordPress 6.1.
• add_filter( 'rest_enabled', '__return_false' ): el filtro está obsoleto desde 4.7. El núcleo remite a rest_authentication_errors en su lugar, y la REST API ya no puede desactivarse de esta forma.

Borrar estas líneas acorta el archivo y facilita la revisión. El código fuente de default-filters.php en 7.1.3 es la referencia con la que comparar.

#Qué entradas de wp_head no conviene eliminar

La limpieza termina donde el núcleo y el editor todavía tienen que funcionar. Cuatro grupos pertenecen a la lista de lo que se conserva.

#Descubrimiento de la REST API

rest_output_link_wp_head escribe un enlace a /wp-json/, y rest_output_link_header envía ese mismo enlace como cabecera HTTP. El editor de bloques, el editor del sitio, muchos plugins de formularios y los front ends de WordPress headless dependen de la REST API. Quitar el enlace de descubrimiento no rompe nada de inmediato, pero a los clientes les cuesta más encontrar el endpoint y resuelves un problema que no existe. Para proteger la REST API, restringe la autenticación y las rutas en lugar de ocultar el enlace.

#CSS del tema y de los plugins

Las hojas de estilo llegan a través de wp_enqueue_style y las imprime wp_print_styles con prioridad 8. Vaciar wp_head por completo o anular todos los estilos destruye el diseño. La limpieza apunta a callbacks legacy del núcleo, no a wp_enqueue_*. Lo mismo vale para los scripts que encolan el tema y los plugins: elimina su registro solo cuando conozcas la dependencia.

#Canonical, Open Graph y meta etiquetas

rel_canonical se queda. Sin canonical te arriesgas a señales de contenido duplicado en variantes con query strings, paginación o parámetros de seguimiento. Las etiquetas Open Graph y sociales de los plugins SEO no se tocan mientras el plugin las configure correctamente.

#Título, robots, iconos y CSS personalizado

_wp_render_title_tag y wp_robots se ejecutan con prioridad 1 e imprimen el <title> y la meta robots. wp_site_icon imprime el favicon con 99 y wp_custom_css_cb imprime el CSS adicional del Personalizador con 101. Nada de esto es bloat.

Los feeds extra, RSD, el generator, los recursos de emoji y los shortlinks son candidatos. REST, CSS, el canonical, el título, robots y los iconos son infraestructura.

#Cómo desactivar los emojis de WordPress sin plugin

Muchos fragmentos eliminan solo el script de detección y se olvidan de los estilos, o al revés. El núcleo mantiene separadas las dos vías, y ambas cambiaron en versiones recientes.

print_emoji_detection_script está enganchada a wp_head con prioridad 7 y a admin_print_scripts. Desde WordPress 6.9 ya no imprime en línea en el head. Programa _print_emoji_detection_script en wp_print_footer_scripts, que genera un bloque JSON de ajustes (id="wp-emoji-settings") y el cargador de emoji como script type="module" antes de </body>. El cargador comprueba si el navegador dibuja los emoji de forma nativa y guarda el resultado en sessionStorage. Solo si la prueba falla añade wp-emoji-release.min.js, que sustituye los emoji por imágenes de s.w.org. En un navegador actual el coste son los ajustes en línea y el código del cargador (el código fuente sin minificar del cargador ocupa unos 13 KB), no la descarga de un polyfill completo.

Los estilos siguieron otro camino. print_emoji_styles quedó obsoleta en 6.4 y la sustituyó wp_enqueue_emoji_styles, que encola un estilo en línea con el handle wp-emoji-styles. Por compatibilidad hacia atrás, el núcleo sigue enganchando print_emoji_styles a wp_print_styles, y la nueva función retorna de inmediato si ese hook se ha eliminado. Por eso remove_action( 'wp_print_styles', 'print_emoji_styles' ) sigue funcionando en 7.1. Una línea equivalente y más directa es remove_action( 'wp_enqueue_scripts', 'wp_enqueue_emoji_styles' ).

Los filtros wp_staticize_emoji (en the_content_feed y comment_text_rss) y wp_staticize_emoji_for_email (en wp_mail) convierten los emoji en imágenes en los feeds y en el correo. En sitios editoriales sin newsletters cargadas de emoji puedes eliminarlos también. Si tus correos de notificación dependen de los emoji, conserva el filtro de correo y limpia solo el front end.

Elimina también los hooks del admin, o los recursos de emoji seguirán en el escritorio. Una limpieza solo del front end ahorra bytes a los visitantes, no a los editores.

#Cómo alojar las imágenes de emoji de WordPress en tu propio servidor

Eliminarlas es una opción. Si quieres mantener el soporte de emoji para navegadores antiguos pero evitar peticiones a un dominio de terceros, apunta las URL base de las imágenes a tu propio servidor. El núcleo ofrece dos filtros para ello: emoji_url para el conjunto PNG y emoji_svg_url para el conjunto SVG. En WordPress 7.1 los valores por defecto son https://s.w.org/images/core/emoji/17.0.2/72x72/ y 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/' );
} );

El segmento de versión de la ruta cambia cuando el núcleo actualiza su conjunto de emoji, así que una copia alojada en tu servidor debe renovarse con las versiones mayores. wp_staticize_emoji usa el mismo filtro emoji_url para los feeds, de modo que un solo cambio cubre ambos sitios.

#Cómo eliminar el shortlink de WordPress y conservar el canonical

wp_shortlink_wp_head escribe <link rel="shortlink" href="https://example.com/?p=42" />. Además, wp_shortlink_header se ejecuta en template_redirect con prioridad 11 y envía una cabecera HTTP Link: <...>; rel=shortlink. Ambos son una comodidad para herramientas antiguas de compartición. Los buscadores siguen el canonical, no el shortlink.

rel_canonical apunta al permalink canónico. El shortlink y el canonical no se contradicen directamente, pero dos señales de URL para el mismo recurso añaden ruido. Fuera el shortlink, dentro el canonical: una preferencia clara por el permalink legible.

Si un plugin de redirecciones o una CDN gestiona URL cortas, revisa una vez las cabeceras de respuesta tras la limpieza en DevTools (Network, luego la petición del documento, luego Response Headers). La cabecera Link con rel=shortlink debería haber desaparecido. El canonical en el HTML sigue visible.

#Cómo eliminar X-Pingback y otras cabeceras HTTP de WordPress

El <head> es solo la mitad de lo que añade WordPress. Tres cabeceras de respuesta proceden del núcleo.

• X-Pingback: desde WordPress 4.4, WP::send_headers() solo la añade en vistas singulares de entradas que aceptan pings. Apunta a xmlrpc.php.
• Link: <...>; rel=shortlink: la envía wp_shortlink_header y se elimina con el código de shortlink anterior.
• Link: <...>; rel="https://api.w.org/": la envía rest_output_link_header. Consérvala por las mismas razones que el enlace REST en el HTML.

Todas las cabeceras que reúne WP::send_headers() pasan por el filtro wp_headers (disponible desde 2.8), así que X-Pingback puede eliminarse ahí:

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

Si los pings están cerrados en una entrada, la cabecera ni siquiera se envía. El núcleo no engancha una etiqueta <link rel="pingback"> a wp_head; si ves una en el código fuente, procede del header.php del tema.

#Limpieza del header en un mu-plugin o en functions.php

Ambos lugares funcionan. La cuestión operativa es la supervivencia.

functions.php en un tema hijo es rápido: SFTP o el editor de temas, guardar y listo. El inconveniente: un cambio de tema o un nuevo tema hijo borra la lógica. Las agencias que cambian los temas de sus clientes pierden la limpieza sin enterarse.

Un plugin must-use en wp-content/mu-plugins/wppoland-clean-head.php se carga automáticamente, sin clic de activación. Un cambio de tema no altera nada. El despliegue mediante Git o rsync sigue siendo sencillo porque el archivo vive fuera del tema. Crea la carpeta una vez y versione el archivo con el resto del proyecto.

Recomendación para sitios en producción: un mu-plugin. Para experimentos puntuales en staging un tema hijo es aceptable, siempre que migres la función más adelante. Evita editar el tema padre; las actualizaciones lo sobrescriben.

Un esqueleto para el mu-plugin:

<?php
/**
 * Plugin Name: WPPoland Clean Head
 * Description: Removes legacy wp_head artefacts.
 * Author: wppoland.com
 * Version: 1.0.0
 */

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

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

La función wppoland_cleanup_head propiamente dicha vive entonces en includes/cleanup-head.php. El archivo de arranque se mantiene corto y fácil de probar. Añade junto a cada eliminación un comentario que explique por qué está ahí:

// Eliminar la detección de emoji: todos los navegadores soportados dibujan los emoji de forma nativa.
remove_action( 'wp_head', 'print_emoji_detection_script', 7 );

#Limpiar wp_head solo en el front end o para headless

Algunas eliminaciones solo tienen sentido en contextos concretos. El ejemplo siguiente conserva el enlace REST cuando una constante propia marca el sitio como headless.

function wppoland_conditional_head_cleanup() {
	// WPPOLAND_HEADLESS es una constante del proyecto definida en 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' );

#Hacer que cada parte de la limpieza se pueda desactivar

En sitios donde las integraciones difieren entre entornos, envuelve cada grupo de eliminaciones en una constante de wp-config.php. Un grupo se ejecuta salvo que su constante esté definida como false:

/**
 * Configúrelo en wp-config.php, por ejemplo:
 * 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' );

Así, staging puede conservar los feeds mientras producción los elimina, sin dos versiones del archivo del plugin.

#Cómo comprobar el header limpio en el código fuente

Tras el despliegue, abre una URL pública en una ventana privada y revisa tres capas.

1. Código fuente (Ctrl+U): busca EditURI, emoji, shortlink, generator y alternate. Desde WordPress 6.9 los ajustes de emoji están antes de </body>, así que busca en todo el documento, no solo en el head. Las coincidencias legacy deberían faltar. El canonical, las hojas de estilo y las etiquetas necesarias de los plugins permanecen.
2. Network en DevTools: filtra por s.w.org y wp-emoji. Tras la limpieza de emoji no debería aparecer ninguna petición. Compara las peticiones del head antes y después del cambio en la misma URL.
3. Cabeceras de respuesta: ninguna cabecera Link con rel=shortlink, y ningún X-Pingback si lo eliminaste. Algunos plugins de seguridad añaden sus propias cabeceras; esas no se ven afectadas.

Lista de comprobación para la validación:

• Prueba staging y producción por separado; vacía la caché de objetos y la caché de página.
• Revisa una entrada individual, una página de archivo y la portada (los feeds extra se comportan de forma distinta en cada una).
• Revisa aparte una página de producto de WooCommerce: los plugins suelen añadir ahí etiquetas que no proceden de este fragmento.
• Abre una vez el editor de bloques y guarda una entrada: la REST API tiene que responder.
• Si quieres, ejecuta PageSpeed Insights o WebPageTest y compara los bytes de HTML y los dominios de terceros. Espera menos ruido, no una puntuación nueva.

Si un script de emoji sigue apareciendo tras la limpieza, comprueba qué plugin lo carga. remove_action sobre hooks del núcleo no detiene a un plugin que encola su propia copia, así que lee el código fuente en lugar de fiarse del fragmento.

#Cómo eliminar los enlaces de feeds RSS del head de WordPress

El RSS no está muerto. Los podcasts, las importaciones de newsletters y las herramientas de monitorización siguen leyendo /feed/. En cambio, los feeds de comentarios y los feeds por taxonomía rara vez traen tráfico y llenan el head de las páginas de archivo.

Niveles pragmáticos:

1. Solo feeds de comentarios (feed_links_show_comments_feed devuelve false). El feed principal se queda.
2. Feeds extra desactivados (eliminar feed_links_extra). Las categorías y etiquetas pierden el autodescubrimiento en el head; las URL de los feeds siguen funcionando para quien las conozca.
3. Todos los enlaces de feed fuera del head (feed_links y feed_links_extra). Los endpoints siguen accesibles, solo desaparece el autodescubrimiento.

El nivel 1 o 2 basta para la mayoría de los sitios corporativos. El nivel 3, solo si nadie se suscribe al feed y lo quiere así a propósito.

feed_links() no imprime nada salvo que el tema declare add_theme_support( 'automatic-feed-links' ). Si un sitio no muestra ningún enlace de feed, revisa el tema antes de añadir código de eliminación.

#Conservar el feed principal y quitar solo algunos feeds extra

Eliminar feed_links_extra es todo o nada. El núcleo ofrece interruptores más finos. feed_links_show_posts_feed y feed_links_show_comments_feed existen desde WordPress 4.4. WordPress 6.1 añadió un filtro por cada tipo de feed extra: 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 y feed_links_extra_show_search_feed. Desde 6.7, feed_links_args filtra el separador y los títulos de los enlaces de feed.

// Conservar el feed de entradas y los feeds de categorías, quitar el resto de los extra.
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 toma por defecto el valor de feed_links_show_comments_feed, así que desactivar el feed global de comentarios también elimina el enlace al feed de comentarios de cada entrada, salvo que devuelvas true para él por separado. La entrada de referencia de feed_links_extra_show_category_feed enumera los parámetros.

#Cómo ocultar la versión de WordPress en el código fuente

wp_generator escribe la versión del núcleo en el HTML. No es una brecha, pero los escáneres dan prioridad a las versiones con CVE conocidas. Elimina la meta etiqueta y vacía the_generator. La versión también se filtra en otros lugares:

1. Query strings de los recursos: los estilos y scripts del núcleo llevan ?ver= con la versión del núcleo, por ejemplo en wp-emoji-release.min.js.
2. readme.html: el archivo está en la raíz de WordPress (/readme.html), no en wp-content, y cada actualización del núcleo lo restaura. Bloquéalo en el servidor web si te importa.
3. Plugins: muchos plugins imprimen su propia versión en comentarios o en las URL de sus recursos.

La limpieza del head no es por sí sola un programa de seguridad; elimina una señal. Lo que cierra las CVE que busca un escáner es actualizar el núcleo y los plugins. Si quieres una revisión completa, consulta la auditoría de seguridad WordPress.

#Quitar el parámetro ver de las URL de CSS y JS

Los filtros style_loader_src y script_loader_src reciben la URL de cada recurso encolado, así que el argumento ver puede eliminarse ahí:

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 );

El parámetro también invalida la caché del navegador y de la CDN tras una actualización. Sin él, un archivo modificado puede servirse desde caché con la misma URL, así que mantén este filtro solo si tu despliegue o tu CDN gestiona la invalidación de caché de otra forma.

#Si rel prev y next siguen aportando beneficios SEO

rel="prev" y rel="next" entre entradas individuales ayudaban antes con las series. En entradas individuales el núcleo no los imprime desde 5.6, así que en un sitio actual proceden del tema o de un plugin SEO. Para los crawlers modernos el efecto es insignificante. En revistas con largas cadenas de artículos puedes conservarlos; en sitios de servicios y tiendas, elimínalos en el plugin que los añade. Pesan más los enlaces internos en el contenido y unos sitemaps sensatos.

#Limpieza del header con WP Rocket y una caché de página

Autoptimize, FlyingPress, WP Rocket y herramientas similares cambian el orden y la combinación de los recursos. Tu fragmento con remove_action debe actuar antes de la caché HTML, es decir, en PHP, no como un reemplazo de cadenas posterior en el optimizador. Si un optimizador vuelve a inyectar scripts de emoji o permite dominios de terceros, revisa su configuración.

Una caché de objetos no guarda la salida de wp_head de forma que deje sin efecto remove_action. Una caché de página sí: las copias HTML antiguas conservan las etiquetas extra hasta que se vacía la caché. Vaciar la caché tras el despliegue es obligatorio.

#Por qué no funciona remove_action en wp_head

Prioridad incorrecta: remove_action( 'wp_head', 'feed_links' ) sin la prioridad 2 no alcanza el callback. El núcleo registra con una prioridad, y tu eliminación tiene que llevar el mismo número.

Hook demasiado temprano: si ejecutas remove_action en el nivel superior de un archivo de plugin, algunos callbacks aún no están registrados. init o wp_loaded son más seguros que el código de nivel superior.

Tema padre editado: llega la actualización y la limpieza desaparece. Usa un tema hijo o un mu-plugin.

REST eliminada desde listas de copiar y pegar: el editor se rompe o las apps headless no encuentran /wp-json/. Las listas de hilos de foros de 2014 son arriesgadas sin comprobarlas; compáralas con la tabla de este artículo.

Nombres de callback obsoletos: la línea apunta a una función que el núcleo ya no engancha, como se enumera en la sección sobre líneas que no hacen nada. La etiqueta que intenta eliminar viene entonces de otro sitio.

Solo se probó el front end: el admin conserva los recursos de emoji. Los visitantes no lo notan, los editores con conexiones lentas sí. Incluya los hooks del admin si el equipo está de acuerdo.

#Resumen

wp_head reúne la salida del núcleo, del tema y de los plugins. Los artefactos legacy (RSD, feeds extra, el generator, los recursos de emoji, el shortlink) se pueden eliminar con remove_action y unos pocos filtros. El descubrimiento REST, el CSS y JS encolados, el título, robots, los iconos y el canonical se quedan. Trata por separado el script y los estilos de emoji, y ten en cuenta que el script se imprime en el footer desde 6.9. Elimina el shortlink en el HTML y en la cabecera HTTP, conserva el canonical. Borra las líneas de wlwmanifest_link y de los enlaces a entradas adyacentes en versiones actuales. La lógica va en un mu-plugin, no en el tema padre. La verificación pasa por una búsqueda en el código fuente, el panel de red y las cabeceras de respuesta, más un vaciado de caché.

Referencias del 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.

Si necesitas ayuda para aplicar esto en staging y en producción, un desarrollador WordPress revisa wp_head junto con el resto de la ruta crítica de renderizado.