Como limpar o cabeçalho WordPress (remover RSS, emojis, shortlinks)

Abra o código-fonte do seu site (Ctrl+U no Windows, Cmd+Option+U num Mac) e desça até à secção <head>. Entre o charset, o viewport e o CSS do tema aparecem muitas vezes uma dúzia de linhas <link>, <meta> e <script> que ninguém da equipa editorial pediu: feeds de comentários, um link de descoberta RSD, um bloco de definições de emoji, um shortlink com ?p=123 e uma meta generator com a versão do core.

Estes artefactos vêm de wp_head(). O core liga callbacks a esse hook, e remove_action() retira o que o seu projeto não precisa. Este guia cobre cada artefacto típico, uma lista segura de remoções verificada em wp-includes/default-filters.php no WordPress 7.1.3, o que deve ficar intacto, a diferença entre o script de emoji e os estilos de emoji, o shortlink versus o canonical, os cabeçalhos ao nível HTTP e a escolha entre um must-use plugin e o functions.php do tema.

O objetivo é menos ruído no HTML e no painel de rede. Remover estas tags não mexe sozinho na pontuação do Lighthouse, mas torna o documento novamente legível e fecha algumas pequenas fugas de informação. Se a meta for o tempo de carregamento, veja a nossa auditoria Core Web Vitals.

#O que o wp_head imprime no cabeçalho WordPress

wp_head é um action hook. Os temas clássicos chamam wp_head() no header.php; os temas de blocos recebem a chamada a partir do template canvas do core. O core e os plugins registam callbacks nele com prioridades. Remover um callback remove apenas a saída desse callback; o hook continua a correr.

Callbacks típicos do core no <head> do front-end do WordPress 7.1, com a prioridade indicada em default-filters.php:

Duas linhas que snippets antigos ainda mencionam já não constam desta lista. wlwmanifest_link foi descontinuado no WordPress 6.3 e já não está ligado a nenhum hook, e adjacent_posts_rel_link_wp_head não é usado pelo core desde a 5.6. Os estilos de emoji passaram de print_emoji_styles para wp_enqueue_emoji_styles na 6.4. Cada uma destas mudanças é tratada mais abaixo.

A tabela substitui o palpite. Antes do primeiro remove_action, veja o código-fonte de uma página de staging e compare-o com esta lista.

Caso real de auditoria em loja WooCommerce no Porto: o <head> tinha 14 tags rel="alternate" (categoria, etiqueta, autor) mais o script de emoji a pedir s.w.org. Depois de remove_action seletivo, o HTML encolheu cerca de 3 KB e desapareceram quatro pedidos no primeiro carregamento. O feed principal manteve-se porque a equipa de marketing ainda usava Feedly.

#Como limpar o cabeçalho WordPress com remove_action

A função abaixo é o núcleo da limpeza. Corre em init, por isso os callbacks que remove já foram registados. A prioridade que indica tem de coincidir com o registo original: feed_links regista-se com 2, feed_links_extra com 3, o script de deteção de emoji com 7. remove_action() aceita três parâmetros (hook, callback, prioridade); o quarto argumento que muitos snippets passam é ignorado.

/**
 * Limpa a secção head do WordPress.
 * Remove links legados, o generator, os assets de emoji e os shortlinks.
 */
function wppoland_cleanup_head() {
	// RSS: links do feed principal e dos feeds extra fora do head.
	remove_action( 'wp_head', 'feed_links', 2 );
	remove_action( 'wp_head', 'feed_links_extra', 3 );

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

	// Meta generator e o generator nos feeds.
	remove_action( 'wp_head', 'wp_generator' );
	add_filter( 'the_generator', '__return_empty_string' );

	// Emoji: script de deteção, estilos, conversão em feeds e e-mail.
	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 no head HTML e no cabeçalho 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 utilização:

• Se ferramentas de newsletter ou agregadores externos leem o seu feed principal, mantenha feed_links e desligue apenas os feeds de que não precisa com os filtros descritos na secção sobre RSS, mais abaixo.
• rsd_link pode sair em praticamente todos os sites públicos. A publicação remota por XML-RPC é, de qualquer forma, um tema de risco à parte.
• the_generator também se aplica ao XML dos feeds. Uma string vazia remove ali também o número da versão.

#Que linhas de remove_action não fazem nada no WordPress 7

Os snippets de limpeza copiados de fóruns trazem linhas que já não correspondem a nada no core. Não estragam o site, porque remove_action() devolve simplesmente false quando o callback não está registado. Mas levam o próximo programador a pensar que a linha está a fazer algum trabalho.

• remove_action( 'wp_head', 'wlwmanifest_link' ): o link do manifesto do Windows Live Writer foi descontinuado no WordPress 6.3. A função agora só emite um aviso de descontinuação e o core já não a liga ao hook. Mantenha a linha apenas se ainda suportar sites abaixo da 6.3.
• remove_action( 'wp_head', 'adjacent_posts_rel_link_wp_head', 10 ): a função ainda existe, mas o seu próprio docblock diz que não é usada no core desde a 5.6. Se vir rel="prev" e rel="next" em artigos individuais, é um tema ou plugin que os acrescenta.
• start_post_rel_link, index_rel_link, parent_post_rel_link: descontinuados no WordPress 3.3. Nenhuma instalação moderna os liga a um hook.
• remove_filter( 'wp_resource_hints', 'wp_dependencies_emoji_styles' ): essa função não existe no core. O DNS prefetch para s.w.org que esta linha devia travar foi removido de wp_resource_hints() no WordPress 6.1.
• add_filter( 'rest_enabled', '__return_false' ): o filtro está descontinuado desde a 4.7. O core aponta para rest_authentication_errors em vez dele, e a REST API já não pode ser desligada desta forma.

Apagar estas linhas torna o ficheiro mais curto e a revisão mais fácil. O código-fonte de default-filters.php na 7.1.3 é a referência com que comparar.

#Que entradas do wp_head não deve remover

A limpeza termina onde o core e o editor ainda precisam de funcionar. Quatro classes pertencem à lista do que fica.

#Descoberta da REST API

rest_output_link_wp_head escreve um link para /wp-json/, e rest_output_link_header envia o mesmo link como cabeçalho HTTP. O editor de blocos, o editor do site, muitos plugins de formulários e os front-ends de WordPress headless dependem da REST API. Remover o link de descoberta não estraga nada de imediato, mas os clientes encontram o endpoint com mais dificuldade e está a resolver um problema que não existe. Para proteger a REST API, restrinja a autenticação e as rotas em vez de esconder o link.

#CSS do tema e dos plugins

As folhas de estilo chegam através de wp_enqueue_style e são impressas por wp_print_styles com prioridade 8. Esvaziar o wp_head por completo ou eliminar todos os estilos destrói o layout. A limpeza visa callbacks legados do core, não wp_enqueue_*. O mesmo vale para os scripts carregados pelo tema e pelos plugins: só os desregiste quando conhecer a dependência.

#Canonical, Open Graph e meta tags

rel_canonical fica. Sem canonical arrisca sinais de conteúdo duplicado em variantes com query strings, paginação ou parâmetros de tracking. As tags Open Graph e sociais dos plugins de SEO ficam intactas, desde que o plugin as defina corretamente.

#Título, robots, ícones e CSS personalizado

_wp_render_title_tag e wp_robots correm com prioridade 1 e imprimem o <title> e a meta robots. wp_site_icon imprime o favicon com 99, e wp_custom_css_cb imprime o CSS adicional do Customizer com 101. Nenhum deles é peso morto.

Feeds extra, RSD, o generator, os assets de emoji e os shortlinks são candidatos. REST, CSS, o canonical, o título, robots e ícones são infraestrutura.

#Como desativar os emojis do WordPress sem plugin

Muitos snippets removem só o script de deteção e esquecem os estilos, ou o contrário. O core mantém os dois caminhos separados, e ambos mudaram em versões recentes.

print_emoji_detection_script está ligado ao wp_head com prioridade 7 e a admin_print_scripts. Desde o WordPress 6.9 já não imprime inline no head. Agenda _print_emoji_detection_script em wp_print_footer_scripts, que emite um bloco JSON de definições (id="wp-emoji-settings") e o loader de emoji como script type="module" antes de </body>. O loader testa se o navegador desenha emoji nativamente e guarda o resultado em sessionStorage. Só quando o teste falha é que acrescenta wp-emoji-release.min.js, que troca os emoji por imagens de s.w.org. Num navegador atual, o custo são as definições inline e o código do loader (o código-fonte não minificado do loader tem cerca de 13 KB), não o download de um polyfill completo.

Os estilos seguiram outro caminho. print_emoji_styles foi descontinuado na 6.4 e substituído por wp_enqueue_emoji_styles, que carrega um estilo inline com o handle wp-emoji-styles. Por compatibilidade, o core ainda liga print_emoji_styles a wp_print_styles, e a nova função termina logo se esse hook tiver sido removido. Por isso remove_action( 'wp_print_styles', 'print_emoji_styles' ) continua a funcionar na 7.1. Uma linha equivalente e mais direta é remove_action( 'wp_enqueue_scripts', 'wp_enqueue_emoji_styles' ).

Os filtros wp_staticize_emoji (em the_content_feed e comment_text_rss) e wp_staticize_emoji_for_email (em wp_mail) convertem emoji em imagens nos feeds e no e-mail. Em sites editoriais sem newsletters cheias de emoji pode removê-los também. Se os seus e-mails de notificação dependem de emoji, mantenha o filtro de e-mail e limpe apenas o front-end.

Remova também os hooks do admin, senão os assets de emoji ficam no painel. Uma limpeza só no front-end poupa bytes aos visitantes, não aos editores.

#Como alojar as imagens de emoji do WordPress no seu servidor

Remover é uma opção. Se quiser manter o suporte de emoji para navegadores antigos mas evitar pedidos a um domínio de terceiros, aponte os URLs base das imagens para o seu próprio servidor. O core disponibiliza dois filtros para isso: emoji_url para o conjunto PNG e emoji_svg_url para o conjunto SVG. No WordPress 7.1 os valores predefinidos são https://s.w.org/images/core/emoji/17.0.2/72x72/ e 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/' );
} );

O segmento da versão no caminho muda quando o core atualiza o seu conjunto de emoji, por isso uma cópia alojada por si tem de ser atualizada nas versões principais. wp_staticize_emoji usa o mesmo filtro emoji_url para os feeds, por isso uma alteração cobre os dois sítios.

#Como remover o shortlink do WordPress e manter o canonical

wp_shortlink_wp_head escreve <link rel="shortlink" href="https://example.com/?p=42" />. Além disso, wp_shortlink_header corre em template_redirect com prioridade 11 e envia um cabeçalho HTTP Link: <...>; rel=shortlink. Ambos são uma conveniência para ferramentas de partilha antigas. Os motores de busca seguem o canonical, não o shortlink.

rel_canonical aponta para o permalink canónico. O shortlink e o canonical não se contradizem diretamente, mas dois sinais de URL para o mesmo recurso acrescentam ruído. Shortlink fora, canonical dentro: uma preferência clara pelo permalink legível.

Num projeto de media em Lisboa, alguém removeu rel_canonical “porque também era um link no head”. Em duas semanas o Search Console mostrou páginas de arquivo com parâmetros UTM a competir com o permalink limpo. O shortlink tinha sido removido corretamente; o erro foi o canónico.

Se um plugin de redirecionamento ou uma CDN gerem URLs curtos, verifique uma vez os cabeçalhos da resposta depois da limpeza nas DevTools (Network, depois o pedido do documento, depois Response Headers). O cabeçalho Link com rel=shortlink deve ter desaparecido. O canonical no HTML continua visível.

#Como remover o X-Pingback e outros cabeçalhos HTTP do WordPress

O <head> é só metade do que o WordPress acrescenta. Três cabeçalhos de resposta vêm do core.

• X-Pingback: desde o WordPress 4.4, WP::send_headers() só o acrescenta em vistas singulares de artigos que aceitam pings. Aponta para xmlrpc.php.
• Link: <...>; rel=shortlink: enviado por wp_shortlink_header, removido com o código do shortlink acima.
• Link: <...>; rel="https://api.w.org/": enviado por rest_output_link_header. Mantenha-o pelas mesmas razões que o link REST no HTML.

Todos os cabeçalhos reunidos por WP::send_headers() passam pelo filtro wp_headers (disponível desde a 2.8), por isso o X-Pingback pode ser removido aí:

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

Se os pings estiverem fechados num artigo, o cabeçalho nem sequer é enviado. O core não liga uma tag <link rel="pingback"> ao wp_head; quando a vir no código-fonte, vem do header.php do tema.

#A limpeza do cabeçalho deve ir num mu-plugin ou no functions.php

Os dois sítios funcionam. A questão operacional é a sobrevivência.

O functions.php num tema filho é rápido: SFTP ou o editor de temas, guardar, feito. A desvantagem: uma troca de tema ou um novo tema filho apaga a lógica. Agências que trocam os temas dos clientes perdem a limpeza sem darem por isso.

Um must-use plugin em wp-content/mu-plugins/wppoland-clean-head.php é carregado automaticamente, sem clique de ativação. Uma troca de tema não muda nada. O deploy por Git ou rsync continua simples, porque o ficheiro vive fora do tema. Crie a pasta uma vez e versione o ficheiro com o resto do projeto.

Recomendação para sites em produção: um mu-plugin. Para experiências pontuais em staging um tema filho é aceitável, desde que migre a função mais tarde. Evite editar o tema pai; as atualizações escrevem por cima.

Um esqueleto para o 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';

A função wppoland_cleanup_head propriamente dita fica então em includes/cleanup-head.php. O ficheiro de arranque mantém-se curto e testável. Acrescente junto a cada remoção um comentário que diga porque está ali:

// Remove a deteção de emoji: todos os navegadores suportados desenham emoji nativamente.
remove_action( 'wp_head', 'print_emoji_detection_script', 7 );

#Limpar o wp_head só no front-end ou para headless

Algumas remoções só fazem sentido em contextos específicos. O exemplo abaixo mantém o link REST quando uma constante própria marca o site como headless.

function wppoland_conditional_head_cleanup() {
	// WPPOLAND_HEADLESS é uma constante do projeto definida no 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' );

#Tornar cada parte da limpeza desligável

Em sites onde as integrações diferem entre ambientes, envolva cada grupo de remoções numa constante do wp-config.php. Um grupo corre a menos que a sua constante esteja definida como false:

/**
 * Configure no wp-config.php, por exemplo:
 * 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' );

Assim o staging pode manter os feeds enquanto a produção os retira, sem duas versões do ficheiro do plugin.

#Como verificar o cabeçalho limpo no código-fonte da página

Depois do deploy, abra um URL público numa janela privada e verifique três camadas.

1. Código-fonte da página (Ctrl+U): procure EditURI, emoji, shortlink, generator e alternate. Desde o WordPress 6.9 as definições de emoji ficam antes de </body>, por isso procure no documento inteiro, não só no head. As ocorrências legadas devem ter desaparecido. O canonical, as folhas de estilo e as tags necessárias dos plugins ficam.
2. Network nas DevTools: filtre por s.w.org e wp-emoji. Depois da limpeza dos emoji não deve aparecer nenhum pedido. Compare os pedidos do head antes e depois da alteração no mesmo URL.
3. Cabeçalhos da resposta: nenhum cabeçalho Link com rel=shortlink, e nenhum X-Pingback se o removeu. Alguns plugins de segurança definem os seus próprios cabeçalhos; esses não são afetados.

Checklist para a verificação de aceitação:

• Teste o staging e a produção em separado; limpe a cache de objetos e a cache de página.
• Verifique um artigo individual, uma página de arquivo e a página inicial (os feeds extra comportam-se de forma diferente em cada uma).
• Verifique à parte uma página de produto WooCommerce: os plugins acrescentam muitas vezes ali tags que não vêm deste snippet.
• Abra uma vez o editor de blocos e guarde um artigo: a REST API tem de responder.
• Opcionalmente, corra o PageSpeed Insights ou o WebPageTest e compare os bytes de HTML e os domínios de terceiros. Espere menos ruído, não uma nova pontuação.

Se um script de emoji continuar a aparecer depois da limpeza, verifique que plugin o carrega. remove_action nos hooks do core não trava um plugin que carrega a sua própria cópia, por isso leia o código-fonte em vez de confiar no snippet.

#Como remover os links de feeds RSS do head do WordPress

O RSS não morreu. Podcasts, importações de newsletters e ferramentas de monitorização ainda leem /feed/. Já os feeds de comentários e os feeds por taxonomia raramente trazem tráfego e enchem o head nas páginas de arquivo.

Níveis pragmáticos:

1. Só os feeds de comentários (feed_links_show_comments_feed devolve false). O feed principal fica.
2. Feeds extra desligados (remover feed_links_extra). Categorias e etiquetas perdem a descoberta automática no head; os URLs dos feeds continuam a funcionar para quem os conhece.
3. Todos os links de feeds fora do head (feed_links e feed_links_extra). Os endpoints continuam acessíveis, só a descoberta automática desaparece.

O nível 1 ou 2 chega para a maioria dos sites empresariais. O nível 3 só se ninguém subscrever o feed e o quiser assim de propósito.

feed_links() não imprime nada a menos que o tema declare add_theme_support( 'automatic-feed-links' ). Se um site não mostrar nenhum link de feed, verifique o tema antes de acrescentar código de remoção.

#Manter o feed principal e retirar só alguns feeds extra

Remover feed_links_extra é tudo ou nada. O core oferece interruptores mais finos. feed_links_show_posts_feed e feed_links_show_comments_feed existem desde o WordPress 4.4. O WordPress 6.1 acrescentou um filtro por 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 e feed_links_extra_show_search_feed. Desde a 6.7, feed_links_args filtra o separador e os títulos dos links de feeds.

// Mantém o feed de artigos e os feeds de categorias, retira os restantes extras.
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 assume como predefinição o valor de feed_links_show_comments_feed, por isso desligar o feed global de comentários remove também o link do feed de comentários de cada artigo, a menos que devolva true para ele em separado. A entrada de referência de feed_links_extra_show_category_feed lista os parâmetros.

#Como esconder a versão do WordPress no código-fonte

wp_generator escreve a versão do core no HTML. Isso não é uma brecha, mas os scanners dão prioridade a versões com CVE conhecidos. Remova a meta tag e esvazie the_generator. A versão também se revela noutros sítios:

1. Query strings dos assets: os estilos e scripts do core levam ?ver= com a versão do core, por exemplo em wp-emoji-release.min.js.
2. readme.html: o ficheiro está na raiz do WordPress (/readme.html), não em wp-content, e é reposto em cada atualização do core. Bloqueie-o no servidor web se isso for importante para si.
3. Plugins: muitos plugins imprimem a sua própria versão em comentários ou nos URLs dos assets.

A limpeza do head, sozinha, não é um programa de segurança; remove um sinal. O que fecha os CVE que um scanner procura é atualizar o core e os plugins.

#Remover o parâmetro ver dos URLs de CSS e JS

Os filtros style_loader_src e script_loader_src recebem o URL de cada asset carregado, por isso o argumento ver pode ser retirado aí:

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

O parâmetro também invalida a cache do navegador e da CDN depois de uma atualização. Sem ele, um ficheiro alterado pode ser servido a partir da cache com o mesmo URL, por isso mantenha este filtro apenas quando o seu deploy ou a sua CDN tratarem da invalidação da cache de outra forma.

#O rel prev e next ainda trazem benefícios de SEO

rel="prev" e rel="next" entre artigos individuais ajudavam antigamente com séries. Para artigos individuais, o core não os imprime desde a 5.6, por isso num site atual vêm do tema ou de um plugin de SEO. Para os crawlers modernos o efeito é desprezável. Em sites de revista com longas cadeias de artigos pode mantê-los; em sites de serviços e lojas, remova-os no plugin que os acrescenta. Os links internos no conteúdo e sitemaps bem pensados pesam mais.

#Limpeza do cabeçalho com WP Rocket e cache de página

Autoptimize, FlyingPress, WP Rocket e ferramentas semelhantes alteram a ordem e a combinação dos assets. O seu snippet de remove_action deve atuar antes da cache de HTML, ou seja, em PHP, e não como uma substituição de texto posterior no otimizador. Se um otimizador voltar a injetar scripts de emoji ou permitir domínios de terceiros, verifique as definições dele.

Uma cache de objetos não guarda a saída do wp_head de forma que torne o remove_action ineficaz. Uma cache de página guarda: cópias antigas do HTML mantêm as tags extra até a cache ser esvaziada. Limpar a cache depois do deploy é obrigatório.

#Porque é que o remove_action no wp_head não funciona

Prioridade errada: remove_action( 'wp_head', 'feed_links' ) sem a prioridade 2 não atinge o callback. O core regista com uma prioridade, e a sua remoção tem de levar o mesmo número.

Hook demasiado cedo: se correr remove_action no nível de topo de um ficheiro de plugin, alguns callbacks ainda não estão registados. init ou wp_loaded são mais seguros do que código no nível de topo.

Tema pai editado: chega a atualização e a limpeza desaparece. Use um tema filho ou um mu-plugin.

REST removida por listas de copiar e colar: o editor deixa de funcionar ou as apps headless não encontram /wp-json/. Listas de tópicos de fóruns de 2014 são arriscadas sem verificação; compare-as com a tabela deste artigo.

Nomes de callbacks obsoletos: a linha visa uma função que o core já não liga a nenhum hook, como listado na secção sobre linhas que não fazem nada. A tag que está a tentar remover vem, nesse caso, de outro sítio.

Só o front-end testado: o admin mantém os assets de emoji. Os visitantes não notam, os editores com ligações lentas notam. Inclua os hooks do admin se a equipa concordar.

#Resumo

O wp_head reúne a saída do core, do tema e dos plugins. Os artefactos legados (RSD, feeds extra, o generator, os assets de emoji, o shortlink) podem ser removidos com remove_action e alguns filtros. A descoberta da REST, o CSS e o JS carregados, o título, robots, os ícones e o canonical ficam. Trate o script de emoji e os estilos de emoji em separado, e saiba que o script é impresso no rodapé desde a 6.9. Remova o shortlink no HTML e no cabeçalho HTTP, mantenha o canonical. Retire as linhas de wlwmanifest_link e dos links para artigos adjacentes nas versões atuais. A lógica pertence a um mu-plugin, não ao tema pai. A verificação passa por uma pesquisa no código-fonte, pelo painel de rede e pelos cabeçalhos da resposta, mais uma limpeza da cache.

Referências do 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.

Precisa de ajuda para aplicar isto em staging e em produção? Um programador WordPress trata o wp_head em conjunto com o resto do caminho crítico de renderização.