Cleaning Up the WordPress Head: Which Tags You Need
Shortlinks, REST and RSD links, oEmbed, the generator tag, emoji, pingback and extra feeds: what each one is, what reads it, and whether to remove it.
In this article 14 sections
View the source of any WordPress page and the <head> holds a dozen lines you never asked for: a shortlink, links to an API, something called RSD, a generator tag, a block of emoji script, several feeds. Guides to "cleaning up the head" tend to say remove them all. Some are safe to remove on nearly every site. Some are in use and removing them breaks something you will not notice for months. This guide goes through them one at a time: what the tag is, what reads it, and how to decide.
One thing first. This is housekeeping. Each tag is a line or two of HTML, and removing it does not improve rankings or produce a speed gain you could measure on most sites. The reasons to do it are narrower and are set out at the end.
How to see what your site prints
Open a post in a private window, so you see what a logged-out visitor gets, and view the page source. Everything between <head> and </head> is what this guide is about. Then open your browser's developer tools, reload, click the first request in the Network tab and look at the response headers. A few of these items are sent as HTTP headers as well as tags.
Write down what you find before changing anything, so you can compare afterwards.
The shortlink
<link rel="shortlink" href="https://example.com/?p=123" />
What it is. A second, shorter address for the same post, built from its ID. It redirects to the full address. WordPress also sends it as a Link HTTP header.
What reads it. The Get Shortlink button that older versions of the editor had, and the occasional sharing tool. Search engines do not need it; your canonical tag already names the address to index.
Decision. Remove it unless you share posts by their ?p= address. Removing the tag does not break those addresses: they still redirect.
The REST API link
<link rel="https://api.w.org/" href="https://example.com/wp-json/" />
What it is. An announcement of where the site's REST API lives. Also sent as a Link header.
What reads it. Software that wants to find the API on a site it knows nothing about, such as some mobile and desktop apps.
Decision. Safe to remove for most sites, with one point to be clear on: this removes the announcement, not the API. The block editor and many plugins use the REST API all the time and call it by its address, so they keep working. Keep the link if an outside app or service connects to your site and finds the API through it.
The RSD link
<link rel="EditURI" type="application/rsd+xml" title="RSD" href="https://example.com/xmlrpc.php?rsd" />
What it is. Really Simple Discovery: a pointer for remote publishing tools to the site's XML-RPC endpoint. Older sites may also print a Windows Live Writer manifest link beside it, for a desktop blogging program that was discontinued years ago.
What reads it. Remote publishing tools and some versions of the mobile app.
Decision. Remove it if you write and publish in the WordPress dashboard and nowhere else.
oEmbed discovery links
<link rel="alternate" title="oEmbed (JSON)" type="application/json+oembed" href="https://example.com/wp-json/oembed/1.0/embed?url=…" />
<link rel="alternate" title="oEmbed (XML)" type="text/xml+oembed" href="…" />
What they are. Two links that let another site turn a pasted address of yours into a preview card.
What reads them. Other WordPress sites, when one of their authors pastes your URL into a post, and some other services that support oEmbed.
Decision. This one is a real trade. Without the links, your posts no longer become rich embeds on other WordPress sites; the pasted address stays a plain link. Previews on social networks are not affected, since those use Open Graph tags. Keep the links if being embedded matters to you. Remove them if it does not.
The generator tag
<meta name="generator" content="WordPress 6.x" />
What it is. A statement of the WordPress version. It also appears in your feeds.
What reads it. Statistics crawlers that count which software sites run, and scanners looking for old versions.
Decision. Remove it; nothing your site needs reads it. Do not mistake that for security. The version can be worked out in other ways, and a site running an old version is no safer for not saying so. Updating is the fix.
The emoji script and styles
What it is. A small inline script and style block that detects whether the browser can draw emoji and, if not, swaps them for images loaded from a WordPress.org address. It is printed on every page.
What reads it. Browsers too old to display emoji themselves.
Decision. Remove it on nearly every site. Current browsers and operating systems display emoji without help, and emoji in your posts stay exactly as typed. It is one of the larger default additions to the head, though still small.
The pingback header and tag
<link rel="pingback" href="https://example.com/xmlrpc.php" />
and, in the response headers, X-Pingback: https://example.com/xmlrpc.php.
What it is. The address other sites use to notify yours when they link to you.
What reads it. Other blogs' software, and a good deal of automated spam.
Decision. If you do not use pingbacks, remove both. Two things to know. First, the tag is often written straight into a theme's header.php, where a plugin switch that works through WordPress's hooks cannot reach it; if it survives, that is why, and the fix is in the theme. Second, removing the announcement does not turn pingbacks off. A site that already knows the address can still send one. To stop accepting them on new posts, untick the pingback option under Settings → Discussion.
Feed links
<link rel="alternate" type="application/rss+xml" title="Site » Feed" href="https://example.com/feed/" />
<link rel="alternate" type="application/rss+xml" title="Site » Comments Feed" href="https://example.com/comments/feed/" />
WordPress creates more feeds than most owners know about:
| Feed | Address | Linked from |
|---|---|---|
| Main feed of posts | /feed/ | Every page |
| All comments on the site | /comments/feed/ | Every page |
| Comments on one post | /a-post/feed/ | That post |
| Posts in a category, tag or by an author | /category/name/feed/ and similar | That archive |
| Results of a search | /search/term/feed/ | That search page |
What reads them. Feed readers, podcast apps, newsletter tools that send from a feed, and crawlers, which fetch feed addresses like any other URL.
Decision. Treat the main feed as untouchable: it is how readers subscribe and how many services pick up your posts. It is also worth making it work for you; see what to put in your RSS feed footer. For the others there are two levels:
- Remove the link from the head. The feed still exists for anyone who has its address; pages simply stop advertising it. This is the mild option, suitable for comment and archive feeds nobody has asked for.
- Turn the feed off and redirect its address to the page it belongs to. Use this when the feed itself is the problem, most often per-post comment feeds on a large site, where every post has an extra address that holds nothing a search engine wants. Anyone subscribed to that feed stops getting updates, so check before you do it.
If your site has no comments at all, the comment feeds are empty and both levels are safe.
Reply links with ?replytocom=
This one is not in the head, and it belongs on the list. With threaded comments on, every comment has a Reply link pointing to the post's address with ?replytocom=123 added. That is a separate crawlable URL for every comment on the site, each showing the same post.
WordPress marks these links nofollow and the pages carry a canonical tag, so they are handled, and crawlers still request a good many of them. The fix is to make the Reply link point at the comment form on the same page. Replies still thread, because the theme's comment-reply script moves the form under the right comment. That script is the dependency: on a theme that does not load it, or in a browser with JavaScript off, the reply is posted as a new top-level comment. Most themes load it. Test one reply after changing this.
How to remove them
In code
Each of these is a WordPress hook, and a few lines in a small plugin or a child theme's functions.php remove them:
add_action( 'init', function () {
remove_action( 'wp_head', 'wp_shortlink_wp_head', 10 );
remove_action( 'template_redirect', 'wp_shortlink_header', 11 );
remove_action( 'wp_head', 'rsd_link' );
remove_action( 'wp_head', 'wp_generator' );
remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
remove_action( 'wp_print_styles', 'print_emoji_styles' );
} );
This works, and it has two drawbacks. The list of hooks is longer than it looks (the generator tag is printed in each feed format separately, and the emoji feature has more hooks than the two above), and the code sits in a file where the next person to look after the site may not find it.
With switches
Hydrogen SEO 0.0.31 puts each item above behind its own switch under Hydrogen SEO → General → Crawl cleanup. There are fourteen, in four groups (Head tags, Feeds, Feeds: turn off and redirect, Headers), and all are off until you turn them on. Each has a line saying what it removes and when to keep it. The main feed cannot be removed or redirected from there. The full list, with the developer filters, is in crawl cleanup.
Whichever way you do it, clear your page cache afterwards and view the source again.
What not to remove
Tidying can go too far. Leave these alone:
- The canonical tag. It tells search engines which address to index. See canonical URL.
- The robots meta tag, including
max-image-preview:large. - Structured data in
application/ld+jsonscript blocks. - Open Graph and Twitter Card tags, which build your link previews.
- The viewport and charset tags.
- The main feed link.
rel="next"andrel="prev"on paginated archives, if your theme or plugin prints them. They do no harm.- Stylesheets and scripts you have not identified. That is a performance project with its own testing, not head cleanup.
Is it worth doing?
There are three sound reasons.
Fewer addresses that hold nothing new. Reply links and per-post comment feeds are the ones that multiply: one per comment and one per post. On a site with thousands of posts and active discussion, that is a large set of URLs for crawlers to request. Whether it affects how your real pages are crawled depends on the size of the site; crawl budget is a concern for very large sites and rarely for small ones.
A head you can read. When you are checking why a meta description or canonical tag is wrong, a head without a dozen unrelated lines is quicker to work in.
Not advertising features you do not use. If nothing publishes to your site remotely and you do not accept pingbacks, the tags announcing those endpoints serve only the bots that look for them.
And one reason that is not sound: expecting a ranking or speed improvement. If someone promises that from removing a generator tag, be sceptical.
On a small site with a handful of posts, leaving everything as WordPress ships it is a perfectly reasonable choice.
A sensible order
- View the source and headers; note what is there.
- Remove the items nothing uses on almost any site: the emoji script, the generator tag, the RSD link, the shortlink.
- Decide on the REST API link, oEmbed links and pingback by asking what connects to your site from outside.
- Look at your feeds. Leave the main one. Remove head links for feeds nobody follows; turn off and redirect only the ones you are sure about.
- If you have threaded comments and many of them, change the reply links, then post a test reply.
- Clear caches, view the source again, and check the site in a second browser.
Related: should you noindex author and date archives?, for the other set of pages WordPress creates without being asked.