Every time one WordPress site links to another WordPress site, the linked site receives an automatic notification called a trackback or pingback. These WordPress trackback and pingback notifications appear in the comments section of the linked post, creating a record of who referenced the content. In theory, this creates valuable cross-blog conversation visibility. In practice, the system is overwhelmingly exploited for spam and has become a significant nuisance for most WordPress site owners. This fits into the wider topic we cover in our WordPress Errors Complete Guide.
WordPress Trackback — What Trackbacks and Pingbacks Are
A WordPress trackback is a notification sent from one site to another when a post links to content on the target site. Pingbacks are an automated, standardised version of the same concept — when WordPress publishes a post with an external link, it automatically sends a pingback request to the linked site using the XML-RPC pingback protocol. Trackbacks are manual (the author sends the notification explicitly) while pingbacks are automatic.
The WordPress trackback and pingback system works as follows: Site A publishes a post linking to a post on Site B → WordPress on Site A sends an XML-RPC request to Site B’s pingback endpoint → Site B receives the notification, fetches Site A’s post to verify the link exists, and if confirmed, creates a comment on the linked post showing Site A’s blog name, post title, and an excerpt. This cross-site linking notification was designed to help authors discover who was discussing their content and to create a visible network of conversation across blogs. When the system works as intended, both sites gain visibility from the connection.
The problem: automated spam bots send fake WordPress trackback and pingback requests that contain links to spam sites rather than genuine references to the content. The pingback endpoint at /wp-json/oembed/1.0/ping (or through XML-RPC) accepts these spam requests and creates spam comments in the moderation queue. On heavily targeted sites, hundreds of spam pingbacks per day flood the moderation queue, making it nearly unusable for monitoring genuine comments. A secondary issue: self-pingbacks occur when a WordPress site links to its own content — WordPress sends a pingback to itself, creating a trackback comment on the linked post from the site’s own domain. According to the WordPress developer documentation, pingbacks use the XML-RPC pingback extension (xmlrpc.php) while the newer approach uses the REST API — both can receive WordPress trackback and pingback requests from external sites.
Disabling WordPress Trackbacks and Pingbacks
For most WordPress sites, completely disabling the WordPress trackback and pingback system eliminates the spam without losing any meaningful functionality — legitimate cross-blog conversation has largely moved to social media, and the few genuine trackbacks sites receive are vastly outnumbered by spam.
Disable for new posts: Settings → Discussion → uncheck “Allow link notifications from other blogs (pingbacks and trackbacks) on new posts” → Save Changes. This disables pingbacks and trackbacks on all new posts created after this change. Existing posts retain their current settings — if they had pingbacks enabled (the default), they continue to receive WordPress trackback notifications.
Disable on existing posts in bulk: Posts → All Posts → select all (and use the “Select all X posts” option to include posts not visible on the current page) → Bulk Actions → Edit → Pings → “Do not allow” → Update. Repeat this for Pages, and for any custom post types that support comments. After this bulk update, no existing post accepts new pingback or trackback requests. For sites with thousands of posts, the bulk update may need to be done in batches if the admin times out on very large selections. The WP-CLI approach handles any quantity: wp post list --format=ids | xargs -d ' ' -I {} wp post update {} --ping_status=closed — this closes pingbacks on every post regardless of type or quantity. Combining the new-post default change with the bulk update of existing posts creates a complete WordPress trackback disable that eliminates all future pingback spam across the entire site. Our guide on managing WordPress spam comments covers the Akismet and referrer-blocking measures that reduce spam comments alongside the pingback disable for comprehensive spam elimination.
Blocking Pingbacks at the Server Level
Disabling WordPress trackback and pingback acceptance in WordPress settings prevents the notifications from appearing in comments, but the spam bots still send requests to the pingback endpoints — consuming server resources processing requests for functionality that is disabled. Server-level blocking eliminates this overhead.
Block WordPress trackback requests at the server level via .htaccess (Apache):
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_METHOD} POST
RewriteCond %{REQUEST_URI} (wp-trackback.php|xmlrpc.php)
RewriteRule .* - [F,L]
</IfModule>This blocks all POST requests to the WordPress trackback endpoint endpoint) and xmlrpc.php (the pingback XML-RPC endpoint). Combined with the Settings → Discussion change, this eliminates both the WordPress-level processing and the server-level resource consumption from spam requests. If XML-RPC must remain active for Jetpack or other legitimate services, block only the pingback method rather than all XML-RPC: a WordPress plugin can add a filter to remove the pingback.ping method from the XML-RPC API while leaving other methods intact: add_filter('xmlrpc_methods', function($methods) { unset($methods['pingback.ping']); unset($methods['pingback.extensions.getPingbacks']); return $methods; }); — this removes only the pingback-related XML-RPC methods, preserving all other XML-RPC functionality including Jetpack’s connection. Our guide on blocking WordPress XML-RPC attacks covers the comprehensive XML-RPC security configuration that contextualises the pingback-specific blocking within the broader XML-RPC threat management strategy.
Self-Ping Prevention and Internal Link Notifications
Self-pings — where a WordPress site sends WordPress trackback notifications to its own posts when internal links appear in new content — create trackback comments from the site’s own domain on linked posts. These are not spam but are unwanted noise in the comment section.
Prevent self-pings without disabling all pingbacks: install the WP No Self Pings plugin (free, 60,000+ installs) → activate → the plugin intercepts outgoing pingback requests and drops any that are directed at the site’s own domain. External pingbacks continue to work while self-pings are silently discarded. This is the correct solution for sites that want to preserve the ability to receive pingbacks from external sites (to be notified when other blogs link to the content) while eliminating the self-notification noise. Without the plugin, adding to functions.php: add_action('pre_ping', function(&$links) { foreach ($links as $l => $link) { if (0 === strpos($link, get_option('siteurl'))) { unset($links[$l]); } } }); — this removes any outgoing pingback URL that starts with the site’s own URL before the pingback is sent.
Existing self-ping WordPress trackback comments that accumulated before self-ping prevention was implemented can be bulk-deleted: Comments → filter to “All” → add a search for the site’s own domain name → all self-ping trackback comments appear → select all → Bulk Actions → Delete Permanently. This cleans the comment section of historical self-pings without affecting genuine comments from real readers. After cleanup, the combination of self-ping prevention (via the filter or plugin) and the WordPress discussion setting to not allow new pingbacks on existing posts maintains a clean comment section going forward. Reviews from the WordPress developer community confirm that disabling pingbacks site-wide via Settings → Discussion and blocking the wp-trackback.php endpoint via .htaccess together eliminate over 99% of all WordPress trackback and pingback spam without requiring any comment-level filtering or Akismet analysis for these specific request types.
Trackbacks vs Comments — Managing the Comment System
The WordPress trackback system adds a type of comment (post_type = trackback or pingback in the comments table) that is distinct from regular reader comments. Understanding this distinction helps manage both systems independently based on the site’s needs.
Regular comments (from readers) and trackbacks/pingbacks are both stored in wp_comments but distinguished by comment_type. A site that wants to disable trackbacks while keeping reader comments open uses the per-post “Discussion” meta box: edit any post → Discussion box → uncheck “Allow trackbacks and pingbacks on this post” while leaving “Allow comments” checked. The Settings → Discussion change described above sets the default for new posts but each post can override the global setting. For selective trackback management on individual posts — enabling trackbacks on specific high-visibility posts where cross-blog conversation is valuable — the per-post control provides the flexibility that global settings cannot.
The database impact of accumulated WordPress trackback spam: thousands of spam trackback comments inflate the wp_comments table, slow comment queries on all pages, and bloat database backups. Bulk clean: phpMyAdmin → SQL → DELETE FROM wp_comments WHERE comment_type = 'trackback' AND comment_approved = 'spam'; — this deletes all spam-flagged trackback comments. Follow with OPTIMIZE TABLE wp_comments; to reclaim the freed database space. For sites with years of accumulated trackback spam before the notification system was disabled, this database cleanup can remove tens of thousands of rows, reducing the wp_comments table size by 50–80% and improving the performance of all admin pages that query comments. After cleanup, the combination of disabled trackback settings, server-level blocking, and Akismet’s spam filtering maintains a clean comment database for new WordPress trackback attempts that reach the WordPress comment system despite the block measures in place. Our guide on managing WordPress revisions and database cleanup covers the same database optimisation approach that applies to trackback spam cleanup as part of broader database maintenance that keeps WordPress running efficiently.
The history of the WordPress trackback system explains why it became so problematic: when Matt Mullenweg introduced trackbacks to WordPress in 2003, the blog ecosystem was a smaller and more collegial space where cross-blog citation was a genuine community practice. The protocol relied on good faith — any site could claim to have linked to any other site, and the receiving site had only a rudimentary verification step (fetching the claimed source URL and checking for the link). Spammers quickly realised the verification was easily spoofed and that trackbacks were effectively an open comment injection mechanism. Despite multiple attempts to improve the protocol, the fundamental design — anonymous, unverified notification from any site to any other — makes spam prevention impossible without limiting the system’s usefulness. Most major blogging platforms have either deprecated or heavily restricted trackback support for this reason, and WordPress’s strong recommendation is to disable the system entirely on any site that does not have a specific, documented need for cross-blog notifications.
Modern alternatives to the WordPress trackback system for cross-blog conversation discovery: Webmentions (an open standard similar to pingbacks but with better spam resistance through sender identity verification), social media mentions monitoring (tracking who references the content on Twitter/X, LinkedIn, and other platforms), and Google Search Console’s Links report (showing all discovered external sites linking to the site, without any notification spam). Each alternative provides the cross-blog conversation visibility that trackbacks were designed for, without the spam vulnerability that makes the original trackback system untenable. The IndieWeb community actively develops Webmention support for WordPress through the Webmention plugin (wordpress.org/plugins/webmention), providing a modern WordPress trackback replacement for sites that want genuine cross-site conversation notifications with better spam resistance than the original trackback protocol. Our guide on WordPress comment moderation covers the comprehensive comment management workflow that applies to all comment types including any remaining legitimate WordPress trackback notifications that reach the moderation queue after the spam reduction measures described in this guide are applied.
The REST API pingback endpoint is a newer vector for WordPress trackback spam that some spam bots have adapted to exploit in addition to the classic xmlrpc.php endpoint. The REST API pingback endpoint at /wp-json/oembed/1.0/proxy can receive pingback-style requests. Block this endpoint specifically if spam is arriving through it: Cloudflare WAF → Custom Rule → URI Path contains “/wp-json/oembed/1.0/proxy” AND Request Method equals “POST” → Block. Alternatively, in .htaccess: RewriteRule ^wp-json/oembed/1.0/proxy - [F,L]. This targeted block stops the REST API pingback vector without disabling the entire REST API. Most WordPress sites do not need this specific endpoint — it is used primarily by oEmbed consumers who want to verify link previews, and its blocking is unlikely to affect any normal WordPress functionality. Monitoring the server access logs for POST requests to this URL pattern after blocking the classic WordPress trackback endpoints confirms whether spam bots are pivoting to the REST API vector and whether the additional block is needed for the specific site’s attack profile.
Monitoring for new WordPress trackback attempts after implementing all the blocking measures confirms whether the configuration is effective or whether bots are finding new endpoints to target. Check server access logs weekly for the first month after implementing WordPress trackback blocking: grep -c "wp-trackback.php|pingback|oembed/1.0/proxy" access.log — a significant reduction in matching log entries (from hundreds per day to near zero) confirms the blocking is working. Any remaining POST requests to blocked endpoints should be returning 403 responses rather than being processed by WordPress. If the count is still high despite .htaccess blocking, the hosting server may be using Nginx rather than Apache and requires equivalent Nginx configuration. Contact the hosting provider to confirm the web server type and get the correct blocking configuration syntax for the specific hosting environment if .htaccess rules are not taking effect as expected.
