The two rel="alternate" tags with application/json+oembed and text/xml+oembed are WordPress oEmbed discovery links. To remove those tags, unhook WordPress’s wp_oembed_add_discovery_links callback from wp_head before it runs, using the priority at which it was registered. This hides the discovery markup; it does not, by itself, disable every part of oEmbed or prove that sensitive data was exposed.
What the two links do
WordPress core adds oEmbed discovery links to the page head through wp_oembed_add_discovery_links(). They tell an embedding consumer where it may request an oEmbed representation of a page. The callback was introduced in WordPress 4.4.0. WordPress’s developer reference describes it as adding “oEmbed discovery links in the head element of the website.” WordPress Developer Resources: wp_oembed_add_discovery_links().
As an Amazon Associate I earn from qualifying purchases.
The callback’s output depends on the page and environment: WordPress emits the JSON link on singular content it considers embeddable, and emits the XML link when SimpleXMLElement is available. Do not assume every page or WordPress installation will show both tags.
The presence of these discovery links is not, on its own, evidence that secured information has been exposed. WordPress documents oEmbed as a way for a consumer site to request embed HTML from a provider and describes security filtering applied to discovered embed content. WordPress Developer Resources: oEmbed.
Remove the discovery callback
Add the unhooking code to a child theme’s functions.php or a site-specific functionality plugin, rather than editing a parent theme file. A SitePoint forum reply recommended those locations so a parent-theme update does not overwrite the change; that advice is not confirmation that the snippet has been tested on the original asker’s installation.
add_action( 'after_setup_theme', function () {
remove_action( 'wp_head', 'wp_oembed_add_discovery_links', 10 );
} );The example uses priority 10, WordPress’s default action priority. If another component registered the callback at a different priority, use that actual priority instead. The callback and priority must match the registration; WordPress notes that removal cannot succeed before registration or after the callback has already run, and a failed removal does not produce a warning. WordPress Developer Resources: remove_action().
Rank #2
Check the result and troubleshoot
- Load a page that previously showed the tags. Inspect its rendered HTML source and search for
application/json+oembedandtext/xml+oembed. - If either tag remains, check timing and priority. Ensure your code runs after the callback has been registered but before
wp_headoutputs it. Confirm that the registration priority is the same value passed toremove_action(). - Check the code location and caches. Confirm the child theme or functionality plugin is active, then clear relevant page or CDN caches before inspecting the output again.
The exact WordPress version, theme, plugins, and live page output in the SitePoint question are not specified, so its reported rest_no_route 404 cannot be diagnosed from that discussion alone.
What this change does not disable
WordPress registers its oEmbed REST route separately through wp_oembed_register_route(). Removing the discovery-link callback only targets the head markup. It is not a complete oEmbed shutdown, does not establish that the REST route is unavailable, and does not remove all publicly available metadata. WordPress Developer Resources: wp_oembed_register_route().
Quick Recap
Rank #3
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
