WordPress pingbacks and trackbacks: what they are and why to disable them

If you have run a WordPress site for more than a few weeks, you have probably seen a notification asking you to approve a pingback or a trackback. Most of the time the comment text is gibberish, the linking site is something nobody has ever heard of, and the link points at a domain selling counterfeit handbags. That is the entire pingback and trackback ecosystem in 2026: a 99% spam channel maintained for backward compatibility with a feature most blogs have not used legitimately in over a decade.

This article explains what pingbacks and trackbacks were originally for, why they are now mostly a nuisance, and how to disable them globally, on existing posts, and at the protocol level so they cannot be abused against your site.

What pingbacks and trackbacks are#

Both are mechanisms from the early blogosphere for one site to notify another that it has linked to it.

Trackbacks came first. The idea was simple: when Blog A wrote a post that linked to a post on Blog B, Blog A’s software sent a small ping to a special trackback URL on Blog B. Blog B then displayed that ping as a comment under the relevant post, with a snippet of Blog A’s text and a link back to Blog A. It was an early attempt at the kind of conversation thread that social media eventually replaced. The ping had to be sent manually or by the author’s blog software; the receiving site had no way to verify the link actually existed.

Pingbacks were the upgrade. Instead of a custom format, they used XML-RPC, and instead of trusting the sender, the receiving site would automatically fetch the source page and confirm the link was actually there before showing the pingback. That made them harder to forge. Pingback support was added to WordPress in 2003 and was on by default. When you wrote a post and linked to another WordPress site that also had pingbacks enabled, your post would automatically appear as a pingback under their post within minutes.

The blogosphere thrived on this for a few years. Inbound trackbacks and pingbacks were a visible signal that other people were reading and citing your work. They were also one of the only practical ways to discover that someone had linked to you.

Why they do not matter any more#

Three things killed pingbacks and trackbacks as a useful feature.

Spam. The first wave of trackback spam started in 2004 and never stopped. Spammers run scripts that send fake pingbacks or trackbacks to thousands of WordPress sites at a time, each one carrying a link to whatever the spammer is selling. Pingbacks are slightly harder to fake than trackbacks because the receiving site verifies the link, but spammers respond by setting up throwaway pages that genuinely contain the link, then sending the pingback. The verification passes; the spam appears in your moderation queue.

Better discovery tools. Google Search Console, Ahrefs, Semrush, and similar tools tell you who is linking to your site with full context, source URL, and link metadata. None of those existed in usable form when pingbacks were designed. Now they do, and they are far more accurate than waiting for a sender to remember to ping you. The SEO basics guide covers Search Console setup, which is where modern backlink discovery lives.

Social media replaced the conversation. In 2026, when someone wants to respond to your post, they tweet or write their own post and tag you. They do not configure their blog to send a trackback to your blog so that a comment appears under your article.

The result is a feature that is on by default, accomplishes nothing useful for the average site, and continuously adds spam to your moderation queue. There is no “good pingback” use case for most sites. Disable them.

Are pingbacks dangerous, not just annoying?#

There is a security angle that goes beyond inbox clutter.

Pingback DDoS reflection. Because XML-RPC pingbacks accept a URL and have your WordPress server fetch that URL to verify the link, attackers can use a large pool of WordPress sites with pingbacks enabled as reflectors in a denial-of-service attack. The attacker sends a pingback request to thousands of WordPress sites, each one claiming a pingback came from the target site. Each victim WordPress server then makes a request to the target to verify. The target gets hammered by traffic from thousands of WordPress installs at once. Your site is not the victim in this scenario; you are the unwitting weapon. Disabling pingbacks removes you from the pool. The full mechanics of credential and protocol abuse against xmlrpc.php are covered in WordPress XML-RPC: what it is and how to disable it, which is the right place to lock the protocol down properly.

Comment table bloat. Pingbacks and trackbacks are stored in the same wp_comments table as regular comments. A site that is heavily targeted by pingback spam can accumulate tens of thousands of pingback rows, all marked as spam, all sitting in the database until a cleanup runs. That bloats backups and slows queries that scan the comments table.

Performance under attack. Each incoming pingback spawns a PHP-FPM worker that opens a connection to the source URL to verify the link. A burst of pingback spam can saturate worker pools the same way other XML-RPC abuse does, and real visitors get 503s while the workers are tied up. The WordPress speed and optimization guide goes deeper on PHP-FPM worker behaviour and how it interacts with traffic spikes.

None of those are catastrophic by themselves, but together they are enough reason to turn the feature off.

How to disable pingbacks and trackbacks on new posts#

The global default lives in Settings > Discussion.

1. In the WordPress admin, go to Settings > Discussion
2. Under Default post settings, uncheck Allow link notifications from other blogs (pingbacks and trackbacks) on new articles
3. Optionally also uncheck Attempt to notify any blogs linked to from the article if you do not want WordPress to send pingbacks when you link out
4. Click Save Changes

That covers all future posts. They will be created with pingbacks and trackbacks disabled. Existing posts are unaffected by this change because each post stores its own pingback setting at the time it was published.

How to disable pingbacks and trackbacks on existing posts#

This is the step most guides skip and the one that actually stops the spam, because the existing posts are what get pinged.

Bulk Edit method (small to medium sites)

1. Go to Posts > All Posts
2. Set the screen options at the top right to show as many posts per page as you can manage (some hosts cap this at 200)
3. Click the checkbox at the top of the list to select all posts on the current page
4. From the Bulk actions dropdown at the top, choose Edit and click Apply
5. In the bulk edit panel, find the Pings dropdown and set it to Do not allow
6. Click Update

Repeat for each page of posts. On a large site this is tedious; jump to the WP-CLI method below.

The same Bulk Edit panel can also turn off comments on existing posts if you want to wind both down together.

WP-CLI method (large sites)

If you have SSH access and WP-CLI installed, one command does the entire site:

wp post list --post_type=post --format=ids | xargs wp post update --ping_status=closed

That sets ping_status to closed on every post in one pass. The same approach works for pages by changing --post_type=post to --post_type=page .

To also close comments at the same time, chain a second command:

wp post list --post_type=post --format=ids | xargs wp post update --comment_status=closed --ping_status=closed

The change is permanent and applies even if you re-enable the global pingback setting later.

Direct database method (advanced, with caution)

If you have phpMyAdmin or a database client and feel comfortable running SQL:

UPDATE wp_posts SET ping_status = 'closed' WHERE post_status = 'publish';

That accomplishes the same thing as the WP-CLI command. Take a database backup first; an unbounded UPDATE against the posts table is hard to undo if you typo the WHERE clause.

Disabling pingbacks at the XML-RPC level#

Disabling the post-level setting stops new pingbacks from being shown on your posts, but the underlying XML-RPC method is still callable. Attackers can still send pingback requests to your xmlrpc.php , and your server will still spend CPU verifying them before discarding the result.

To stop them entirely, you have to either disable XML-RPC or filter the specific pingback methods.

Filter just the pingback methods (XML-RPC stays available for other clients):

add_filter('xmlrpc_methods', function($methods) {
    unset($methods['pingback.ping']);
    unset($methods['pingback.extensions.getPingbacks']);
    return $methods;
});

Drop that into a child theme’s functions.php or a small site-specific plugin. After it loads, requests for those two methods return an unknown-method error and never reach the link-verification code.

Disable XML-RPC entirely. If nothing on your site uses XML-RPC (the WordPress mobile app, Jetpack, third-party publishing tools), you can turn the whole protocol off. The full breakdown of why and how, with three different methods at the plugin, theme, and web-server layer, is in WordPress XML-RPC: what it is and how to disable it. Disabling XML-RPC also closes off the brute-force amplification vector covered in brute force attacks on WordPress, which is a separate problem from pingback abuse but lives at the same endpoint.

What about self-pings?#

A self-ping is a pingback that fires when you link from one of your own posts to another of your own posts. WordPress treats it as any other pingback, sends it to your own site, and your own site dutifully verifies the link and creates a pingback comment. This used to clutter the comment thread on every internal-link-heavy article.

If self-pings annoy you specifically, you have two options:

1. Disable pingbacks globally (which you should already be doing for the spam reasons above).
2. Install the No Self Pings plugin if you want to keep external pingbacks but suppress self-pings only. The plugin is small and well-maintained, and it adds a check that aborts the pingback before it gets stored if the source and destination domains match.

Option 1 is the right call for almost everyone.

Common mistakes#

• Disabling the global setting and assuming existing posts are covered. They are not. The setting only applies to posts created after the change. Existing posts keep whatever ping status they had when they were published. Use Bulk Edit or WP-CLI to update them.
• Disabling pingbacks but leaving XML-RPC fully exposed. XML-RPC has other abuse vectors beyond pingbacks (credential brute force via system.multicall ). Turning off pingbacks only is fine if you actively use XML-RPC for something else, but if you do not, lock down the whole protocol.
• Marking pingback spam as spam in moderation instead of disabling pingbacks. Akismet and similar plugins can catch most pingback spam, but every pingback still triggers the link-verification fetch on your server before reaching the moderation queue. Disabling pingbacks at the source stops the work from happening at all.
• Thinking pingbacks help with SEO. They do not. Inbound pingbacks add a comment-style link to your post, but the link is to the source site, not a backlink to you. Search engines have ignored the SEO signal from pingback comments for over a decade. Pingbacks have no positive ranking effect.
• Leaving “Attempt to notify any blogs linked to from the article” enabled. This is the outbound side: WordPress sending pings when you link out. It is rarely useful (the receiving site usually has pingbacks disabled too) and adds latency to every publish operation while WordPress contacts each linked URL. Turn it off.

How Hostney handles pingback abuse#

Hostney’s nginx layer rate-limits POST requests to /xmlrpc.php per IP per minute, which catches the worst of the pingback flood and credential-stuffing volume before it reaches PHP. The bot-detection layer also flags automated xmlrpc.php POST patterns as part of its general abuse scoring, so a sender that hammers pingback endpoints across multiple sites on the platform gets challenged or blocked at the edge rather than tying up your worker pool. None of that replaces disabling pingbacks at the application layer; it is a backstop.

If you have already disabled pingbacks both globally and at the post level, the only remaining traffic to xmlrpc.php is brute-force attempts and the occasional legitimate XML-RPC client. The general guidance to harden a WordPress install (covered in is WordPress secure and how to harden it) covers the broader posture; pingbacks specifically are a one-time setting change that takes about three minutes and pays off forever.

Summary#

Pingbacks and trackbacks were a useful feature in the early blogosphere and are now a near-pure source of spam, server load, and one specific DDoS reflection vector. To remove them: uncheck the pingback option in Settings > Discussion to cover new posts, run Bulk Edit or wp post update --ping_status=closed against existing posts to cover the back catalogue, and either filter the pingback XML-RPC methods or disable XML-RPC entirely to stop the underlying protocol from being callable. Five minutes of work removes a category of spam, a category of abuse, and a small ongoing performance tax that has no upside on a modern WordPress site.