WordPress head tags you can safely remove

WordPress adds a surprising amount of markup to the document <head> before your theme, SEO plugin and other extensions contribute anything of their own.

Some of that output is essential.

Some is useful only when the corresponding WordPress feature is actually used.

And some can often be removed safely from modern sites without affecting normal page rendering, indexing or administration.

The important word is safely.

A clean WordPress head is not the one with the fewest possible tags. It is the one that keeps the metadata, styles, scripts and discovery mechanisms the site genuinely needs while removing only output that serves no purpose for that particular project.

Deleting the wrong head element can break:

• canonicalization;
• SEO directives;
• stylesheets;
• JavaScript dependencies;
• site icons;
• resource loading optimizations;
• REST-dependent functionality;
• embeds;
• feed discovery;
• third-party integrations.

This guide focuses specifically on the WordPress-generated head tags that can commonly be removed, explains what each one does, distinguishes discovery removal from feature disabling, and identifies the tags you should generally leave alone.

Where WordPress head output comes from

Most WordPress themes include:

<?php wp_head(); ?>

inside the page’s <head> element.

The official wp_head() documentation explains that this function fires the wp_head action.

WordPress core, themes and plugins attach callbacks to that action and print their own markup.

Core callbacks currently include functionality related to:

• the document title;
• styles and scripts;
• resource hints;
• RSS feeds;
• RSD discovery;
• Windows Live Writer discovery;
• emoji support;
• WordPress version information;
• canonical URLs;
• shortlinks;
• site icons.

The official wp_head hook reference is particularly useful because it lists many of the default core callbacks and their priorities.

Not every WordPress site outputs exactly the same head

Before removing anything, remember that the final document head depends on several layers.

These include:

• WordPress version;
• active theme;
• theme supports;
• SEO plugin;
• performance plugin;
• security plugin;
• block or classic theme architecture;
• current page type;
• enabled WordPress features;
• custom code.

For example, a singular post can expose different metadata from a category archive.

An SEO plugin can replace canonical handling.

An oEmbed-enabled post can output discovery markup that is absent elsewhere.

Always audit the rendered site rather than assuming one generic cleanup snippet applies perfectly to every installation.

What does “safe to remove” actually mean?

In this context, a head tag is generally safe to remove when all of the following are true:

• the corresponding feature is not required;
• removing the tag does not break normal frontend rendering;
• it does not remove an important SEO signal;
• it does not remove access control or security functionality;
• it does not break an integration the site uses;
• the underlying functionality can remain available if only discovery is being removed.

This last distinction appears repeatedly.

Removing a discovery tag often means:

Stop advertising the feature

not:

Disable the feature itself

1. The WordPress generator tag

WordPress can output a generator meta tag containing the CMS name and version.

It can resemble:

<meta name="generator" content="WordPress 6.x" />

The official wp_generator() documentation confirms that this function displays the XHTML generator information through wp_head.

Can you safely remove it?

For most websites, yes.

The generator tag is not required for:

• page rendering;
• WordPress administration;
• search-engine indexing;
• permalinks;
• the REST API;
• RSS feeds;
• normal theme functionality.

A typical removal is:

remove_action( 'wp_head', 'wp_generator' );

Does removing it hide WordPress?

No.

It removes one explicit version signal, but WordPress can still be identified through many other characteristics.

For the broader reasoning, see Why Hide Your WordPress Version Number? and How Attackers Fingerprint WordPress Sites.

2. The WordPress shortlink tag

WordPress can advertise a short alternative URL for singular content:

<link rel="shortlink" href="https://example.com/?p=123" />

The official wp_shortlink_wp_head() documentation confirms that this function injects a rel="shortlink" element when a shortlink exists.

Can you safely remove it?

Usually, yes.

Removing the head element does not normally interfere with the site’s pretty permalink.

It also does not necessarily disable WordPress’s underlying ability to understand URLs such as:

?p=123

A typical removal is:

remove_action( 'wp_head', 'wp_shortlink_wp_head', 10 );

If you are cleaning shortlinks comprehensively, remember that WordPress can also expose a matching HTTP Link header separately from the head element.

See What Is the WordPress Shortlink, and Do You Need It?.

3. RSD discovery

WordPress can advertise a Really Simple Discovery document through markup similar to:

<link
    rel="EditURI"
    type="application/rsd+xml"
    title="RSD"
    href="https://example.com/xmlrpc.php?rsd"
/>

The corresponding WordPress function is:

rsd_link()

RSD historically helped external publishing clients discover remote editing APIs such as XML-RPC.

Can you safely remove it?

On many modern sites, yes, provided no legacy publishing client depends on RSD discovery.

The removal is:

remove_action( 'wp_head', 'rsd_link' );

Does this disable XML-RPC?

No.

This is another discovery-versus-functionality distinction.

Removing the RSD tag does not necessarily make:

/xmlrpc.php

unavailable.

For the full relationship, see What Is the RSD Tag in WordPress? and XML-RPC in WordPress, Explained.

4. Windows Live Writer manifest discovery

WordPress can also advertise a Windows Live Writer manifest using:

wlwmanifest_link()

The output resembles:

<link
    rel="wlwmanifest"
    type="application/wlwmanifest+xml"
    href="https://example.com/wp-includes/wlwmanifest.xml"
/>

This exists for compatibility with Windows Live Writer and related historical remote publishing workflows.

Can you safely remove it?

For most contemporary WordPress websites, yes.

Unless the site specifically depends on software that uses this discovery mechanism, the tag usually provides little practical value.

Remove it with:

remove_action( 'wp_head', 'wlwmanifest_link' );

5. RSS feed discovery links

WordPress can automatically advertise RSS feeds through <link rel="alternate"> elements.

For example:

<link
    rel="alternate"
    type="application/rss+xml"
    title="Example Site Feed"
    href="https://example.com/feed/"
/>

General and contextual feed discovery is generated primarily through:

feed_links()
feed_links_extra()

The official feed_links_extra() documentation shows that contextual discovery can include category, tag, taxonomy, author, search, post comments and post type archive feeds.

Can you safely remove these links?

Yes, if the website does not need automatic feed discovery.

A typical cleanup is:

remove_action( 'wp_head', 'feed_links', 2 );
remove_action( 'wp_head', 'feed_links_extra', 3 );

Does this disable RSS?

No.

The actual feed URLs can remain accessible.

This exact distinction is covered in How WordPress Advertises RSS Feeds by Default and Hiding vs. Disabling WordPress Feeds.

6. oEmbed discovery links

WordPress can advertise oEmbed representations of singular content.

The official wp_oembed_add_discovery_links() documentation shows that WordPress can output JSON and XML oEmbed discovery links.

They can resemble:

<link
    rel="alternate"
    type="application/json+oembed"
    href="..."
/>

<link
    rel="alternate"
    type="text/xml+oembed"
    href="..."
/>

Can you safely remove them?

Yes, if you do not want external consumers automatically discovering that your content can be embedded.

However, understand the scope of the change.

Removing the discovery markup is narrower than completely disabling WordPress oEmbed functionality.

See How to Disable oEmbed in WordPress and WordPress oEmbed Privacy and Security, Explained.

7. REST API discovery links

WordPress can advertise its REST API from the document head.

Depending on the current output, this can include a link identifying the API endpoint.

The relevant core callback is:

rest_output_link_wp_head()

Can you safely remove it?

Usually, yes, if the objective is only to remove REST API discovery markup.

This does not mean the REST API itself should be disabled.

That distinction is particularly important because modern WordPress functionality can depend heavily on REST endpoints.

See How WordPress Advertises Its REST API and Hiding vs. Restricting the WordPress REST API.

Do not disable the REST API just to clean the head

The WordPress REST API is used by:

• the Block Editor;
• plugins;
• administration interfaces;
• frontend applications;
• remote integrations;
• custom JavaScript interfaces.

Removing a discovery tag and restricting the actual API are fundamentally different operations.

Before restricting anything broader, see What Depends on the WordPress REST API.

8. Emoji detection output

WordPress historically added frontend JavaScript and related assets to provide emoji compatibility for browsers that lacked native support.

The wp_head callback includes:

print_emoji_detection_script()

On modern browsers, this fallback is often unnecessary for many websites.

Can you safely remove it?

In many modern environments, yes.

But emoji cleanup is broader than simply deleting one head element because WordPress emoji support can involve multiple hooks and styles.

If the goal is to remove the feature cleanly, use a complete emoji-disable implementation rather than deleting isolated output until the page source looks quieter.

See Why WordPress Loads an Emoji Script on Every Page.

9. Adjacent post relational links

WordPress can output relational links for adjacent posts using:

adjacent_posts_rel_link_wp_head()

These can indicate previous or next content relationships.

Can you safely remove them?

Usually, yes, if the site does not rely on them and another system is not intentionally using that metadata.

They are not required for WordPress’s normal visible previous/next navigation.

The visible navigation in the page body can continue working independently.

A removal can be performed with:

remove_action( 'wp_head', 'adjacent_posts_rel_link_wp_head', 10 );

As always, test whether any custom theme or crawler workflow expects the metadata before removing it globally.

10. Pingback discovery links added by a theme

Some themes or custom code may output:

<link rel="pingback" href="https://example.com/xmlrpc.php" />

This is not necessarily emitted by current WordPress core through the same standard callback list as the other entries in this guide.

A theme can add it manually.

Can you safely remove it?

If you do not need pingback discovery, generally yes.

But again:

remove pingback discovery
≠
disable pingbacks
≠
disable XML-RPC

See Pingbacks, Trackbacks & Internal Links for the underlying relationship.

Tags you should not remove casually

Head cleanup becomes dangerous when every unfamiliar tag is treated as waste.

Several outputs should generally remain unless you understand exactly what replaces them.

Keep the document title

Modern WordPress themes commonly use:

add_theme_support( 'title-tag' );

and WordPress handles the document title through its normal title system.

The resulting:

<title>...</title>

is fundamental for:

• browser tabs;
• search results;
• accessibility;
• document identification.

Do not remove title handling as part of generic head cleanup.

Keep canonical URLs unless another system replaces them correctly

WordPress can output canonical markup through:

rel_canonical()

A canonical tag might look like:

<link rel="canonical" href="https://example.com/example-post/" />

Canonical URLs help search engines understand the preferred URL for substantially equivalent content.

Removing them without an SEO plugin or another correct replacement can weaken URL consolidation signals.

See WordPress Canonical URLs, Explained.

Do not remove robots directives blindly

A document can include robots metadata such as:

<meta name="robots" content="noindex, follow" />

or other directives generated by WordPress or an SEO plugin.

These may be intentionally controlling search-engine behavior.

Removing them because they look like generic metadata can cause indexing changes.

Do not remove stylesheets simply because there are many of them

WordPress and plugins commonly print stylesheet references through:

<link rel="stylesheet" ...>

These are not the same kind of optional discovery metadata discussed above.

Removing them can immediately break page styling.

If the problem is excessive CSS, solve it through:

• conditional enqueueing;
• asset unloading;
• plugin cleanup;
• CSS optimization;
• theme architecture.

Do not simply delete generated stylesheet tags from the final HTML.

Do not remove scripts without dependency analysis

JavaScript loaded in the head may support:

• WordPress core functionality;
• forms;
• analytics;
• consent systems;
• navigation;
• interactive blocks;
• plugins;
• third-party integrations.

The correct approach is to identify the registered script and dequeue it only when it is genuinely unnecessary.

Do not remove resource hints globally without understanding them

WordPress can generate resource hints using:

wp_resource_hints()

The official wp_resource_hints() documentation shows that WordPress can output hints used to prepare connections or resource loading.

Examples can include relationships such as:

dns-prefetch
preconnect

Removing the entire:

wp_resource_hints

callback just to eliminate one unwanted hint can also remove useful performance hints added by WordPress or plugins.

When possible, filter only the specific entry you do not want.

Do not remove preload or modulepreload links casually

Modern WordPress, themes and plugins can use preload-related metadata to optimize resource loading.

A link such as:

<link rel="preload" ...>

may be intentionally prioritizing a critical resource.

Removing it without profiling can make performance worse rather than better.

Keep the site icon unless you intentionally replace it

WordPress can output favicon/site-icon markup through:

wp_site_icon()

This affects:

• browser tabs;
• bookmarks;
• device interfaces;
• shortcut representations.

If the site uses a WordPress-configured site icon, removing the output without replacing it is normally a regression.

Keep viewport metadata on responsive sites

The viewport meta tag often comes from the theme rather than WordPress core:

<meta
    name="viewport"
    content="width=device-width, initial-scale=1"
/>

This is fundamental to normal responsive behavior.

It is not cleanup material.

Keep charset declarations

A typical theme includes:

<meta charset="UTF-8">

or an equivalent value generated from the WordPress charset configuration.

This tells the browser how to interpret the document encoding.

Do not remove it.

Be careful with SEO plugin output

SEO plugins may generate:

• title metadata;
• meta descriptions;
• canonical tags;
• robots directives;
• Open Graph metadata;
• Twitter Card metadata;
• schema markup.

These tags may make the head look considerably larger than WordPress core’s default output.

That does not make them unnecessary.

Audit what each tag does before removing anything generated by an SEO system.

Be careful with Open Graph metadata

Open Graph tags can control how pages appear when shared on social platforms.

Examples include:

<meta property="og:title" content="..." />
<meta property="og:description" content="..." />
<meta property="og:image" content="..." />

These are unrelated to WordPress’s legacy discovery clutter.

Removing them can degrade social-sharing previews.

Be careful with structured data

JSON-LD such as:

<script type="application/ld+json">
...
</script>

may represent schema markup for:

• articles;
• organizations;
• breadcrumbs;
• products;
• people;
• other entities.

Do not remove structured data as part of a generic WordPress head cleanup unless you have confirmed it is invalid, duplicated or unnecessary.

A practical WordPress head cleanup set

For a modern site that does not use the corresponding legacy discovery features, a focused cleanup can look like this:

add_action(
    'after_setup_theme',
    function () {

        // WordPress version generator.
        remove_action( 'wp_head', 'wp_generator' );

        // RSD discovery.
        remove_action( 'wp_head', 'rsd_link' );

        // Windows Live Writer manifest.
        remove_action( 'wp_head', 'wlwmanifest_link' );

        // WordPress shortlink discovery.
        remove_action( 'wp_head', 'wp_shortlink_wp_head', 10 );

        // RSS feed discovery.
        remove_action( 'wp_head', 'feed_links', 2 );
        remove_action( 'wp_head', 'feed_links_extra', 3 );

        // Adjacent post relationship links.
        remove_action( 'wp_head', 'adjacent_posts_rel_link_wp_head', 10, 0 );
    }
);

This should be treated as an example, not as a mandatory recipe for every WordPress installation.

The correct set depends on which features the site actually uses.

Why use remove_action() instead of editing WordPress core?

WordPress’s hook system is specifically designed to let plugins and themes modify behavior without editing core files.

The official remove_action() documentation explains how registered callbacks can be detached from actions.

Editing files such as:

wp-includes/default-filters.php

or:

wp-includes/general-template.php

is the wrong approach.

Core modifications can:

• be overwritten by WordPress updates;
• complicate maintenance;
• make troubleshooting harder;
• create undocumented differences between environments.

Priority matters when removing actions

An action must generally be removed using the same callback and priority with which it was registered.

For example:

add_action( 'wp_head', 'feed_links', 2 );

is removed with:

remove_action( 'wp_head', 'feed_links', 2 );

If the priority is wrong, the callback may remain registered.

The wp_head reference is useful for checking current core priorities.

Some WordPress behavior changes between versions

Head cleanup snippets copied from old tutorials deserve scrutiny.

WordPress core evolves.

Callbacks can:

• change priority;
• gain filters;
• change output;
• be deprecated;
• move to different execution paths.

For example, current WordPress versions include more nuanced oEmbed discovery handling than older snippets may assume.

Use current Developer Resources rather than treating a ten-year-old functions.php snippet as permanent API documentation.

Should you remove everything listed in this guide?

No.

The objective is not:

remove every optional WordPress tag

It is:

remove every optional WordPress tag that serves no purpose on this site

Those are very different standards.

A publication actively using RSS should not remove feed discovery merely because another website does.

A site relying on oEmbed should not remove embed discovery without understanding the consequences.

A remote publishing environment may still need RSD-related functionality.

Performance impact of head cleanup

Removing small metadata tags reduces HTML size slightly.

The improvement is normally tiny.

Deleting:

• one generator tag;
• one shortlink;
• one RSD link;
• a few RSS discovery links;

will not transform Core Web Vitals.

The larger performance gains normally come from optimizing:

• JavaScript;
• CSS;
• images;
• fonts;
• third-party scripts;
• database work;
• server caching;
• network delivery.

Security impact of head cleanup

Some removable tags expose information about available WordPress functionality.

Removing them can reduce passive discovery signals.

Examples include:

• the generator tag;
• RSD discovery;
• REST discovery;
• shortlinks;
• feed discovery.

But hiding discovery does not secure the associated endpoints.

An attacker can still probe predictable locations such as:

/xmlrpc.php
/wp-json/
/feed/

without seeing them advertised first.

Therefore head cleanup is supplementary hygiene, not a security boundary.

SEO impact of head cleanup

Removing genuinely unnecessary discovery metadata is generally neutral for SEO.

Problems arise when cleanup starts removing important SEO output.

Be especially cautious with:

• canonical tags;
• robots directives;
• titles;
• structured data;
• Open Graph metadata;
• hreflang;
• SEO-plugin-generated metadata.

The safe rule is simple:

Legacy/discovery metadata
→ evaluate for removal

Search and document metadata
→ keep unless intentionally replaced

How TheOneWP approaches WordPress head cleanup

TheOneWP treats WordPress head cleanup as a collection of focused features rather than one indiscriminate switch that removes every optional line of markup.

This makes it possible to remove only the output that is unnecessary for the current website.

Examples include dedicated controls for:

• WordPress version output;
• RSD discovery;
• RSS feed discovery;
• shortlinks;
• REST API discovery;
• emoji support;
• oEmbed functionality.

This modular approach matters because the safest configuration differs from one website to another.

A site might reasonably want:

WordPress version output      removed
RSD discovery                 removed
Shortlink discovery           removed
RSS discovery                 kept
REST discovery                kept
oEmbed                        kept
Canonical URL                 kept

Another project can require a different combination.

How to audit your current WordPress head

1. View the rendered page source

Inspect the actual HTML delivered to the browser.

Do not rely only on theme files because plugins can add output dynamically.

2. Search for common WordPress markers

Useful search terms include:

generator
EditURI
wlwmanifest
shortlink
application/rss+xml
oembed
api.w.org
canonical
dns-prefetch
preconnect

3. Identify the source of each element

Determine whether it comes from:

• WordPress core;
• theme;
• SEO plugin;
• performance plugin;
• security plugin;
• custom code.

4. Determine whether the corresponding feature is used

Do not remove first and investigate later.

5. Apply the narrowest possible change

If one resource hint is unnecessary, filter that hint instead of deleting every resource hint.

If only RSS discovery is unnecessary, remove discovery rather than disabling feeds automatically.

6. Clear caches

Head markup can be cached by:

• page caches;
• server caches;
• CDNs;
• optimization plugins.

7. Test multiple page types

Check:

• homepage;
• single post;
• page;
• category;
• tag;
• search results;
• custom post type archive.

Common WordPress head cleanup mistakes

Removing everything from a copied snippet

A snippet written for another site does not know your dependencies.

Confusing discovery removal with feature disabling

This repeatedly affects:

• RSS;
• REST API;
• XML-RPC/RSD;
• shortlinks;
• oEmbed.

Removing canonical tags

This can weaken URL consolidation signals if nothing replaces them.

Removing resource hints indiscriminately

Useful connection optimizations can disappear with the unwanted ones.

Editing WordPress core files

Use hooks and filters instead.

Assuming fewer head tags always means faster pages

Metadata cleanup has a tiny impact compared with real asset optimization.

Assuming hidden endpoints are secure

Predictable WordPress routes can still be requested directly.

Removing SEO-plugin markup because it was not generated by the theme

Source does not determine usefulness.

Testing only the homepage

Many WordPress head elements are contextual.

WordPress head tags cleanup checklist

• Inspect the rendered document head before making changes.
• Confirm the active WordPress version.
• Identify which markup comes from WordPress core.
• Identify theme-generated head output.
• Identify plugin-generated head output.
• Remove the WordPress generator tag if you do not want version metadata exposed.
• Remove shortlink discovery if the site does not need it.
• Remember that removing shortlink discovery does not disable ?p=ID routing.
• Remove RSD discovery if no legacy remote-publishing client requires it.
• Remember that removing RSD does not disable XML-RPC.
• Remove the Windows Live Writer manifest when unused.
• Remove RSS discovery only if automatic feed discovery is unnecessary.
• Remember that removing RSS discovery does not disable feed endpoints.
• Remove oEmbed discovery only after checking embed requirements.
• Distinguish oEmbed discovery removal from full oEmbed disabling.
• Remove REST discovery only when that metadata is unnecessary.
• Do not disable the REST API merely to clean the head.
• Review emoji support separately rather than deleting one isolated hook.
• Remove adjacent-post relational links only if no system requires them.
• Keep the document title.
• Keep canonical URLs unless another system replaces them correctly.
• Keep intentional robots directives.
• Keep stylesheet links unless the corresponding assets are genuinely unused.
• Keep required JavaScript.
• Keep site-icon output unless intentionally replaced.
• Keep viewport metadata.
• Keep charset metadata.
• Review resource hints individually rather than removing them globally.
• Do not remove preload hints without performance testing.
• Keep valid Open Graph metadata when social sharing matters.
• Keep valid structured data.
• Use WordPress hooks instead of editing core files.
• Match callback priorities correctly when using remove_action().
• Clear all relevant caches after changes.
• Test multiple frontend page types.
• Test integrations related to any feature whose discovery markup was removed.
• Do not describe head cleanup as major performance optimization.
• Do not treat it as a substitute for actual WordPress security controls.

Related guides

• Cleaning Up WordPress’s Default Head Output
• What Is the RSD Tag in WordPress?
• What Is the WordPress Shortlink, and Do You Need It?
• How WordPress Advertises RSS Feeds by Default
• How WordPress Advertises Its REST API

Final recommendation

WordPress head cleanup is useful when it is selective.

The generator tag, shortlink discovery, RSD discovery, Windows Live Writer manifest and other legacy or optional discovery elements can often be removed safely when the site does not use the functionality they advertise.

RSS, REST API and oEmbed discovery deserve slightly more thought because removing their head markup is not the same as disabling the underlying services.

That distinction should remain deliberate.

If you want less metadata, remove discovery.

If you want a feature unavailable, configure or disable the feature separately.

Do not extend the cleanup mindset to canonical tags, robots directives, titles, stylesheets, required scripts, site icons, resource-loading optimizations or valid SEO metadata merely because they make the document head longer.

A longer head is not automatically a bad head.

The goal is not to minimize the number of lines. The goal is to make every remaining line intentional.

Start with an audit, identify which WordPress callbacks are actually responsible for each element, remove only the output the site does not need, then verify multiple frontend contexts after clearing caches.

That produces a cleaner WordPress document head without turning routine optimization into accidental feature removal.