A trackback is a notification that one blog has cited another. It's a clever 2003 idea that survived just long enough to become a permanent attack surface on a sizeable fraction of the WordPress web. If you run a WP site that predates the latest install, there is a non-trivial chance you're still accepting trackbacks today, even if you'd forgotten the feature exists.
What trackbacks were originally for
Trackback was introduced by Six Apart for Movable Type in 2002, with a sibling protocol called pingback emerging the year after. The mental model: if you wrote a post that referenced someone else's post, your blog would ping theirs to say "I just cited you, here's the link." Their site would render a list of incoming citations near the comments. Two blogs talking about the same topic would form a small visible web of references — readers could follow citations forward and backward, and the early blogosphere genuinely worked this way for a few years.
The protocols are simple. A trackback is an HTTP POST to a discoverable endpoint with a few form fields (title, excerpt, url, blog_name). A pingback is the same idea wrapped in XML-RPC: the sender calls pingback.ping on the receiver's XML-RPC endpoint with the source and target URLs. The receiver fetches the source URL, confirms the link exists, and renders the citation.
Why spammers love them
Look at that mechanism from the perspective of someone who wants backlinks at scale:
- Auto-discoverable. Every WordPress install historically advertised an
xmlrpc.phpendpoint at a predictable path. A spammer can scan the web for responsive endpoints faster than they can find email addresses to phish. - No rate limit by default. A single host can issue thousands of pingbacks an hour with no authentication. Verification of the source URL is the only check, and "verification" means the spammer puts a real link on a real spam page.
- Renders inline. A successful trackback shows up on the target page as a citation block near the comments — same visual weight as a comment, often without the "via XML-RPC" indicator that would let a reader spot the difference.
- Doubles as a DDoS amplifier. The
pingback.pingmechanism makes the receiver fetch an attacker-supplied URL. Point thousands of pingback-enabled WordPress sites at the same target URL and you have an unintentional botnet. This pattern was prolific enough in the mid-2010s that it has its own write-ups under "WordPress pingback DDoS."
Why every modern platform disabled them
Discourse, Ghost, Substack, Hugo and Eleventy with the common comment plug-ins, every static-site CMS — none of them implement trackbacks or pingbacks. The protocols were declared dead by most of the industry between 2014 and 2018, and new comment platforms simply don't ship them. There's no equivalent in any modern spec.
The reason is that the upside disappeared as the downside grew. The "blogosphere talking to itself" use case was replaced by Twitter, then by referral logs, then by Mastodon and friends. Nobody clicks on the trackback list at the bottom of a post anymore — it's just a vector. The cost of running it (spam moderation, occasional DDoS amplification incidents, security CVEs in XML-RPC parsers) stayed the same. Disabling was the obvious call.
WordPress, in 2026
WordPress is the holdout, and it's the holdout for a legacy-compatibility reason. Pingbacks remain enabled by default on new installs, and xmlrpc.php is reachable on the public internet unless an admin has explicitly blocked it. The Discussion settings page exposes a checkbox labeled "Allow link notifications from other blogs (pingbacks and trackbacks) on new posts" — checked by default, unchecked by every security-conscious WordPress hardening guide published in the last decade.
The compounding problem: even if you uncheck that setting for new posts, existing posts retain whatever per-post override they were created with. A blog migrated from a 2010 install can have thousands of pingback-enabled posts even if the global toggle is off.
How to handle it
For most sites the right answer is to disable both protocols and forget they exist. Concretely:
- Block
xmlrpc.phpat the web server. One nginxlocationblock returning 403, or one Apache<Files>directive. This also closes off the historical brute-force vector againstwp.getUsersBlogs, which is a separate but related XML-RPC abuse pattern. - Disable pingbacks and trackbacks globally. Settings → Discussion, uncheck the "Allow link notifications" box. Then run a one-shot SQL update to override per-post settings:
UPDATE wp_posts SET ping_status = 'closed'; - Set
comment_pings_opento false in functions.php if you want insurance against future regressions on the global setting.
If you have a specific reason to keep them on (some legacy academic sites still genuinely use citation pingbacks), treat the inbound payload exactly like a comment: classify the excerpt and source page text against a spam model before rendering anything. The /v1/predict endpoint doesn't care whether the text came from a comment form, a contact form, or an XML-RPC pingback — it scores text. Wire the pingback handler through it and stop accepting unscored citations.
The shorter version
Trackbacks are a vestigial feature on most of the web and a default-on liability on WordPress. There's no working modern use case that justifies leaving them enabled, and the failure modes (spam citation rendering, DDoS amplification, brute-force surface) are all real. Disable at the web server, disable at the application, and if you must keep them on, classify everything that comes in.