Cleaning up WordPress’s default head output

WordPress adds more to a page’s <head> than most site owners ever configure manually.

Some of that output is essential. The document title, stylesheets, scripts, canonical URLs, robots directives, site icons and resource hints can all support normal rendering, search behavior or browser functionality.

Other entries exist for compatibility, discovery or features that a particular website may not use. Examples can include the Really Simple Discovery link, shortlink advertising, RSS autodiscovery links, REST API discovery links, oEmbed discovery links, WordPress generator information and emoji fallback assets.

Cleaning up WordPress’s default head output means reviewing those entries deliberately and removing only the ones the site does not need.

It does not mean deleting wp_head(), stripping every unfamiliar tag, or copying an old optimization snippet without checking what current WordPress actually does.

That distinction matters because wp_head() is one of the most important hooks on the front end. WordPress core, themes and plugins use it to print or enqueue functionality that can be required for rendering, SEO, APIs, embeds and application behavior.

A safe cleanup process therefore follows a simple rule: understand the output first, remove the discovery or compatibility layer only when it is unnecessary, and verify that the underlying feature behaves exactly as intended afterward.

What WordPress puts in the document head

WordPress themes normally call wp_head() before the closing </head> tag. The function fires the wp_head action, which gives WordPress core, plugins and themes a shared place to add front-end data.

The official wp_head hook documentation describes it as the hook used to print scripts or data inside the front-end head element.

Core attaches a number of callbacks to that hook. Depending on the current request, theme support and active plugins, the output may include:

• the document title;
• preload and resource hints;
• RSS and Atom discovery links;
• RSD discovery;
• robots directives;
• emoji detection assets;
• styles and scripts;
• WordPress generator information;
• canonical links;
• shortlinks;
• REST API discovery;
• oEmbed discovery;
• site icon markup;
• custom CSS;
• plugin- and theme-specific metadata.

Not every item appears on every page

Many callbacks are conditional.

For example, WordPress core’s rel_canonical() outputs a canonical link only for singular queries. oEmbed discovery links are relevant only when the current singular content is embeddable. Feed output depends on theme support and the type of request.

When auditing the head, therefore, do not inspect only the homepage. Check representative posts, pages, archives and any important custom post types.

The current WordPress version matters

Old cleanup tutorials often contain removals for functionality that no longer produces output.

A useful example is wlwmanifest_link(). WordPress deprecated it in version 6.3 because the Windows Live Writer manifest is no longer included in core, so modern WordPress no longer outputs that manifest link through the function.

Copying old head-cleanup snippets without checking current core can therefore add dead code while missing newer behavior.

Why clean up WordPress head output?

Head cleanup can have legitimate benefits, but those benefits should be described accurately.

Reduce unnecessary discovery markup

If a site does not use a legacy discovery mechanism, there may be no reason to advertise it on every page.

Removing an unused RSD link or shortlink element makes the document more intentional and reduces the number of public implementation clues.

Reduce minor markup and asset overhead

Removing a few link elements saves very little data by itself. It should not be treated as a dramatic performance optimization.

Some related cleanup decisions can matter more. Removing an unused emoji fallback system or disabling a complete embed feature can eliminate scripts, styles, discovery output or processing that the site genuinely does not need.

The impact still depends on the exact feature and page.

Reduce unnecessary fingerprinting signals

Generator information, RSD output, REST discovery and characteristic WordPress links can help automated tools recognize the platform and its public capabilities.

Removing unnecessary disclosure can make low-effort reconnaissance less convenient.

It does not make WordPress invisible. Paths, assets, markup, API behavior and many other signals can still reveal the platform. See How Attackers Fingerprint WordPress Sites for the broader picture.

Make ownership of technical output clearer

On complex sites, several plugins can attempt to manage overlapping metadata. A deliberate audit makes it easier to identify duplicate canonicals, duplicate feed links, repeated meta tags or multiple systems trying to control the same concern.

The purpose is not minimal HTML for its own sake. The purpose is a predictable head in which every important entry has a known owner and reason to exist.

Which WordPress head entries can often be removed?

The answer depends on the site’s functionality. The following entries are common cleanup candidates, but none should be removed merely because it looks unfamiliar.

Really Simple Discovery link

WordPress’s rsd_link() function prints a link to the site’s Really Simple Discovery endpoint at xmlrpc.php?rsd.

RSD was designed to help external publishing clients discover services offered by a site. If the project does not use software that depends on RSD discovery, the link may provide no practical value.

Removing the RSD link does not by itself disable xmlrpc.php. Those are separate decisions.

If XML-RPC itself is part of the concern, read What Is XML-RPC in WordPress, and Why Disable It?.

WordPress shortlink

The wp_shortlink_wp_head() function can advertise a compact ?p=ID-style URL for singular content.

Modern sites normally promote their readable permalink instead, so the shortlink element may be unnecessary.

There is an important second layer: WordPress can also emit the shortlink as an HTTP Link header. A complete shortlink cleanup should therefore inspect response headers as well as HTML source.

Removing the advertised tag and header does not have to disable the underlying ?p=ID route.

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

WordPress generator output

wp_generator() prints WordPress generator information through wp_head.

If the exact WordPress version does not need to be public, removing generator output is a reasonable reconnaissance-reduction measure.

However, generator cleanup is only one disclosure point. Feeds and asset version parameters can expose version-related information separately.

For the full distinction between useful hardening and actual vulnerability remediation, see Why Hide Your WordPress Version Number?.

REST API discovery links

WordPress’s rest_output_link_wp_head() prints the REST API root into the page head and can also advertise a JSON representation of the current resource.

WordPress also sends REST discovery information through an HTTP Link header.

If a project does not need public autodiscovery, those hints can be removed independently of the REST API itself.

This distinction is critical. Removing discovery markup is not the same as disabling API routes, authentication or Block Editor functionality.

For the actual API security model, see WordPress REST API Security Basics.

RSS and Atom autodiscovery links

The feed_links() function outputs links to general feeds when the current theme supports automatic feed links. feed_links_extra() can output contextual feeds for categories, tags, authors, searches, post types and comments.

If a site still uses RSS, the discovery links can be useful for feed readers and other clients.

If automatic feed discovery is unnecessary, the links can be removed while leaving the feed endpoints available.

That is different from disabling RSS feeds entirely.

oEmbed discovery links

WordPress can expose JSON and XML oEmbed discovery links for embeddable singular content through wp_oembed_add_discovery_links().

These links allow other software to discover how the current WordPress post can be embedded.

Since WordPress 6.9, core runs this callback first at wp_head priority 4, while retaining the original priority-10 registration for backward compatibility. The function itself checks whether the older priority-10 hook is still present before printing.

That detail is important because old snippets that blindly assume one registration priority may no longer describe current core accurately.

If the site does not need oEmbed functionality, removing only the discovery links is still only a partial change. WordPress also has oEmbed routes, provider handling and embed scripts.

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

Emoji fallback assets

WordPress includes an emoji detection system intended to provide fallback behavior where native emoji support is insufficient.

The core print_emoji_detection_script() function participates in that system.

On projects that are comfortable relying on modern browser, operating-system and font emoji support, disabling WordPress’s fallback assets can remove a small amount of front-end support code.

This should be tested rather than assumed, particularly on projects with unusual compatibility requirements.

What should usually stay in the WordPress head?

A cleanup checklist becomes dangerous when every line is treated as removable.

The document title

Modern themes normally support WordPress’s title-tag system. The title is fundamental to the document and search presentation.

Do not remove title rendering as part of generic cleanup.

Canonical URLs

WordPress core’s rel_canonical() prints canonical links for singular queries.

Canonical URLs help search engines understand the preferred representative when duplicate or parameterized URLs exist.

Removing canonical output merely to reduce markup is usually counterproductive.

See WordPress Canonical URLs, Explained.

Robots directives

WordPress can output robots directives according to the current request and configuration.

These directives can affect indexing and crawler behavior. Do not remove them as generic head noise.

Stylesheets and scripts

WordPress’s enqueue system places required assets through the head and footer.

If a stylesheet or script is unnecessary, dequeue the specific asset after understanding its dependency chain. Do not remove the core printing functions from wp_head as a shortcut.

Resource hints and preloads

DNS prefetch, preconnect, preload and other hints can be deliberate performance signals.

They should be audited individually. A hint pointing to an unused origin may be removable; a preload for an important resource may be beneficial.

Site icon and intentional metadata

Favicon markup, SEO metadata, social metadata and verification tags may all live in the head for legitimate reasons.

The correct question is not “Did WordPress output this?” but “Does the site need this, and which system owns it?”

How to remove default head output safely with WordPress hooks

WordPress provides a hook system specifically so developers can change behavior without editing core files.

The official remove_action() documentation notes that the callback and priority must match the original registration.

This is why current source matters.

A focused cleanup example

The following example removes several discovery-oriented entries while deliberately leaving canonical URLs, titles, scripts, styles and robots behavior alone:

add_action(
    'after_setup_theme',
    function () {
        remove_action( 'wp_head', 'rsd_link' );
        remove_action( 'wp_head', 'wp_generator' );
        remove_action( 'wp_head', 'wp_shortlink_wp_head', 10 );
        remove_action( 'template_redirect', 'wp_shortlink_header', 11 );

        remove_action( 'wp_head', 'rest_output_link_wp_head', 10 );
        remove_action( 'template_redirect', 'rest_output_link_header', 11 );

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

This is an example architecture, not a universal recommendation to remove every listed item.

If your site uses RSS autodiscovery, keep the feed links. If external clients depend on RSD, keep RSD. If API clients rely on REST discovery, keep those hints.

Do not edit wp-includes or default-filters.php

Core updates will overwrite direct edits, and modifying core makes maintenance and troubleshooting harder.

Put deliberate site-level behavior in a plugin, must-use plugin or another maintainable project-specific layer.

Be careful with oEmbed removal on current WordPress

Because WordPress 6.9 changed when oEmbed discovery runs, a current implementation should not be based on an old assumption that the callback exists only at priority 10.

WordPress retains the original priority-10 registration specifically for backward compatibility with existing removal code, while running the callback earlier at priority 4. For complete oEmbed shutdown, remove or filter the broader system intentionally rather than treating one head link as the whole feature.

Removing discovery links does not necessarily disable the feature

This is the most important conceptual distinction in WordPress head cleanup.

RSD link removal is not XML-RPC shutdown

Removing rsd_link stops the HTML from advertising the RSD endpoint.

It does not automatically block requests to xmlrpc.php.

REST discovery removal is not REST API shutdown

Removing rest_output_link_wp_head and the related HTTP header removes discovery hints.

The API root and registered routes can still work normally.

This is often desirable because the Block Editor and plugins can depend on the REST API even when public discovery markup is unnecessary.

RSS link removal is not RSS feed shutdown

Removing feed_links and feed_links_extra stops HTML autodiscovery.

Known feed URLs can still respond unless the feed endpoints themselves are separately disabled.

Shortlink advertisement removal is not route removal

The ?p=ID address can continue resolving even when the head tag and HTTP header disappear.

oEmbed discovery removal is not complete oEmbed removal

WordPress’s embed system includes more than discovery markup. There are REST routes, provider resolution, rendering logic, embed responses and scripts.

If the goal is to prevent oEmbed behavior rather than merely hide discovery links, treat that as a separate feature-level change.

This distinction allows much safer configuration. You can remove unnecessary advertising without accidentally disabling functionality the site still needs.

Performance, security and SEO: what head cleanup really changes

Head cleanup is often marketed with exaggerated claims. The real benefits are more modest and more specific.

Performance gains from markup-only cleanup are small

Removing a few <link> elements reduces HTML by a small amount.

That is legitimate cleanup, but it is rarely a meaningful Core Web Vitals optimization by itself.

Performance benefits become more relevant when a cleanup decision also removes actual scripts, styles, third-party requests or processing.

For example, unnecessary embed systems can trigger substantially more work than a single discovery tag. See Why Third-Party Embeds Slow Down WordPress.

Security benefits are mostly attack-surface and disclosure related

Removing generator or discovery information can reduce easy fingerprinting.

Disabling an unused underlying service can reduce attack surface.

Those are different levels of change.

Removing the REST discovery link does not secure an incorrectly permissioned REST endpoint. Removing the RSD tag does not close XML-RPC. Removing a WordPress version string does not patch outdated software.

SEO benefits come from correctness, not minimalism

Search engines do not reward a site simply because its head has fewer lines.

Canonical URLs, robots directives and relevant metadata should remain correct and consistent.

Feed discovery or shortlink markup may be unnecessary for a particular site, but removing SEO-critical output to produce cleaner source code would be the wrong tradeoff.

Privacy can be relevant when cleanup removes external activity

Some WordPress functionality can lead to requests involving third-party providers. That is more significant than removing inert markup.

When privacy is the reason for cleanup, audit actual network requests and data flows instead of judging the page only by source length.

See WordPress Privacy and Third-Party Requests.

How TheOneWP handles WordPress head cleanup

TheOneWP separates head cleanup into focused modules instead of presenting one irreversible “remove everything” switch.

That approach matters because discovery markup and underlying functionality are often separate concerns.

Disable RSD Link

Disable RSD Link removes the legacy Really Simple Discovery link from the document head.

It targets the discovery output rather than claiming to disable XML-RPC as a whole.

Disable REST API Links

Disable REST API Links removes public REST API discovery links and headers while leaving the REST API itself operational.

This is useful when you want cleaner public discovery output without breaking features that still depend on REST routes.

Disable RSS Feed Links

Disable RSS Feed Links removes feed autodiscovery tags from the head while keeping feed URLs available.

If the requirement is to disable the feeds themselves, that is a separate control.

Disable Shortlink

Disable Shortlink removes both the shortlink head element and its matching HTTP header while leaving standard ?p=ID routing untouched.

Disable WordPress Version Number

Disable WordPress Version Number handles WordPress core version disclosure beyond the basic generator tag, including feed output and visible asset-version parameters.

Disable Emojis

Disable Emojis removes WordPress emoji detection scripts, related inline styles, DNS prefetching and the TinyMCE emoji plugin while leaving normal Unicode emoji characters in stored content untouched.

Disable Embeds

Disable Embeds is intentionally broader than head cleanup. It removes WordPress embed scripts, discovery links and related embed behavior, with controls for retaining providers the site actually uses.

The modular distinction is useful: remove only the output or functionality that matches the project’s actual requirement.

How to audit and test a cleaned WordPress head

A cleanup is not complete when the snippet saves without a PHP error. It is complete when you have verified the resulting site behavior.

Inspect rendered HTML source

Check several representative front-end URLs and verify which elements remain.

Useful targets include:

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

Inspect HTTP response headers

Not everything lives in HTML.

Shortlink and REST discovery information can also appear in HTTP Link headers.

Use browser developer tools, curl -I, a crawler or another HTTP inspection tool.

Test the underlying endpoints separately

If you removed only discovery output, confirm that the underlying feature has the state you intended.

• Does the REST API still work if you meant to keep it?
• Do RSS feeds still work if you removed only autodiscovery?
• Does ?p=ID still resolve after shortlink cleanup?
• Is XML-RPC actually disabled if that was a separate requirement?
• Do existing embeds still render?

Check SEO-critical output

Confirm that you still have the intended:

• title;
• canonical URL;
• robots directives;
• meta description where provided by your SEO layer;
• structured data where applicable;
• hreflang where applicable.

Check scripts, styles and front-end behavior

Navigate important user flows and review the browser console for errors.

If you disabled emoji or embed functionality, test pages that actually contain emojis or embeds instead of assuming the absence of an obvious visual regression proves success.

Clear caches before judging the result

Page cache, server cache and CDN cache can continue serving old HTML after hooks change.

Purge the appropriate cache layer and retest the final response.

Document the cleanup

Record which default outputs were removed and why.

This becomes valuable when another developer later needs to understand why a REST discovery link, feed link or shortlink is missing.

WordPress head cleanup checklist

• Keep wp_head() in the theme.
• Audit current WordPress output rather than relying on old snippets.
• Inspect more than the homepage.
• Identify which plugin or theme owns each important meta tag.
• Keep the document title.
• Keep correct canonical output.
• Keep intentional robots directives.
• Do not remove core script and style printing functions as generic cleanup.
• Remove the RSD link only if RSD discovery is unnecessary.
• Remember that removing RSD does not disable XML-RPC.
• Remove shortlink advertising only if no client depends on it.
• Inspect both the shortlink head element and HTTP header.
• Remove REST discovery only if clients do not require autodiscovery.
• Do not confuse REST discovery removal with REST API shutdown.
• Remove RSS autodiscovery only if the site does not need it.
• Decide separately whether feed endpoints should remain accessible.
• Treat oEmbed discovery and complete oEmbed functionality as separate concerns.
• Test emoji removal on the browsers and content that matter to the project.
• Remove WordPress version disclosure without treating it as a security patch.
• Check response headers as well as HTML.
• Clear caches after changing head output.
• Verify SEO-critical metadata after cleanup.
• Document every removal so future maintenance remains understandable.

Related guides

• What Is the WordPress Shortlink, and Do You Need It?
• WordPress Canonical URLs, Explained
• How to Disable oEmbed in WordPress
• WordPress oEmbed Privacy and Security, Explained
• Why Third-Party Embeds Slow Down WordPress
• WordPress REST API Security Basics
• Why Hide Your WordPress Version Number?
• How Attackers Fingerprint WordPress Sites
• What Is XML-RPC in WordPress, and Why Disable It?
• WordPress Privacy and Third-Party Requests

Final recommendation

Cleaning up WordPress’s default head output is worthwhile when it is treated as configuration hygiene rather than a contest to produce the shortest possible HTML source.

Start by identifying what WordPress, the active theme and plugins actually output on the current version of the site. Separate essential document and SEO data from legacy discovery links, optional compatibility features and assets the project does not use.

Then remove narrowly.

If you do not need RSD, remove RSD discovery. If you do not want shortlink advertising, remove the head element and matching header while leaving normal routing alone. If you do not need REST autodiscovery, remove its links without disabling an API required by the editor. If you do not use RSS discovery, remove the discovery tags while deciding separately whether the feeds themselves should remain available.

The same logic applies to oEmbed, emojis and version disclosure: understand whether you are removing a hint, an asset or the complete underlying feature.

Finally, verify HTML, response headers, endpoints, SEO metadata and real front-end behavior after the change.

A clean WordPress head is not one with the fewest tags. It is one in which every remaining tag, script, link and directive has a known purpose.