Your comment section should welcome real conversations, not a pile of automated link notices. The good news is you can disable WordPress pingbacks without turning off normal visitor comments.
It takes a few minutes to handle the right settings, clean up older posts, and decide whether XML-RPC needs tighter protection. Start with the simple fix, then add security layers that fit how your site runs.
Key Takeaways
- You can disable WordPress pingbacks without turning off regular visitor comments.
- Turn off pingbacks and trackbacks in Settings > Discussion, then bulk-edit older posts and pages separately.
- Keep internal links in place by filtering self-pingbacks rather than removing useful links.
- Disabling pingbacks does not block XML-RPC. Check whether Jetpack, the WordPress mobile app, or remote publishing tools rely on it before restricting
xmlrpc.php. - Test comments, internal linking, connected tools, and your recovery plan after making changes.
What Pingbacks Do, and Why Comments Stay Separate
Pingbacks are automated notifications sent when one website links to another. WordPress can receive, approve, and display them alongside comments.
They aren’t the same as comments. WordPress keeps these settings separate, so you can close the door on pingback spam while keeping customer questions, product feedback, and community conversations open.
Pingbacks and trackbacks are close, but not identical
A trackback is a manual notification. The site owner sends it to tell another site about a linked post.
A pingback is automatic. WordPress checks that a link exists before sending the notification, which sounds tidy in theory. In practice, both can fill a moderation queue with noise. The official WordPress explanation of trackbacks and pingbacks breaks down their original purpose.
Self-pingbacks are internal-link clutter
A self-pingback appears when one post links to another post on the same site. Useful internal linking can make related articles appear as internal notifications.
That isn’t a hack. It’s clutter in the moderation workflow, not a reason to remove helpful links. Still, it can make a busy comment section feel messy fast.
Why Disable WordPress Pingbacks?
Pingbacks were built for a more social version of blogging. Most small business sites don’t need them now, so you can disable WordPress pingbacks without closing your comments.
Spam is one reason to turn them off. Security is the bigger one. A pingback request uses the WordPress XML-RPC endpoint, usually found at xmlrpc.php. Attackers can abuse it to send requests through many WordPress sites toward one target.
Pingbacks can add noise and risk
A flood of pingback spam wastes moderation time. Worse, attackers can use pingback requests in a reflection attack. They can prompt vulnerable sites to request a target URL, creating unwanted traffic that may contribute to DDoS attacks.
XML-RPC can also be abused for password guessing during brute-force attacks. Cloudflare documented how system.multicall could pack many login attempts into one request in its report on WordPress brute-force amplification attacks.
Turning off pingbacks stops link notifications. For broader WordPress security, review unused XML-RPC functions separately. That protection is a separate decision from disabling pingbacks.
Comments do not need to disappear
You don’t need to choose between security and engagement. Leave your regular comment setting active, then turn off only pingbacks and trackbacks.
That distinction matters for service businesses, stores, and blogs that rely on real questions from real people in the comment section.
Disable WordPress Pingbacks in Global Discussion Settings
This is the fastest place to start. It applies the rule to new posts you publish after saving the setting.
In your WordPress dashboard, go to Settings > Discussion. Look for these two options:
- “Attempt to notify any blogs linked to from the post”
- “Allow link notifications from other blogs (pingbacks and trackbacks) on new posts”
Uncheck both boxes, then select Save Changes.
Keep “Allow people to submit comments on new posts” checked if you still want visitor comments. WordPress lists these as separate discussion options, so changing the pingback setting does not close comments.
One important detail: this global change doesn’t update older content. Those posts need their own cleanup.
Turn Off Pingbacks on Individual Posts and Pages
Need to control one post without changing the whole site? Open that post or page in the WordPress editor.
Find the Discussion panel. Depending on your WordPress version and editor setup, it may sit in the right-hand settings sidebar or lower on the edit screen. Uncheck the option that allows pingbacks and trackbacks, but leave the comments option enabled.
Then update the post.
This is useful for a page that attracts unwanted link notifications, while you still want pingbacks elsewhere. WordPress confirms that the post editor has separate discussion controls for comments and pingbacks.
Bulk Edit Existing Posts to Remove Active Pingbacks
Older posts are where most site owners get caught. You disable WordPress pingbacks for future content, then old articles keep accepting them.
Head to Posts > All Posts. Select the posts you want to update, choose Edit from the Bulk actions menu, and click Apply. In the bulk editor, set Pings to “Do not allow,” then select Update.
Repeat the process in Pages > All Pages if your pages also allow pings. On larger sites, work in batches and verify the first batch before moving on.
A few dashboard labels may differ by WordPress version. The setting you need always refers to pings, pingbacks, or trackbacks. It does not refer to ordinary comments.
Stop self-pingbacks While Keeping Internal Links
Internal linking helps visitors find related services, guides, and product pages. Don’t stop linking just to avoid self-pingbacks.
You have two clean options. The first is to turn off incoming pingbacks globally, which is simplest when outside pingbacks aren’t useful. The second preserves internal linking while filtering only links that point back to your own domain.
For a focused plugin alternative, No Self Ping blocks internal notifications without replacing your comment system. Shield Security PRO provides broader WordPress protection and can complement this targeted approach. Before enabling overlapping notification or security controls, review plugin settings. If Shield Security PRO is active, review its Shield Security PRO settings as well.
Use a small code snippet for internal links
The displayed PHP code snippet filters self-pingbacks before WordPress sends notifications. Place this code snippet in a custom site plugin or maintained tool such as the WPCode plugin. Avoid editing functions.php directly unless you manage a child theme and have a recovery plan:
function zadic_stop_self_pingbacks( &$links ) {
$home = get_option( 'home' );
foreach ( $links as $key => $link ) {
if ( 0 === strpos( $link, $home ) ) {
unset( $links[ $key ] );
}
}
}
add_action( 'pre_ping', 'zadic_stop_self_pingbacks' );
Test this code snippet on a staging site first. Also check that your WordPress Address and Site Address use the same canonical domain. A mismatch between www and non-www versions can let some self-pings slip through.
Keep your comment workflow clean
Once self-pingbacks stop, review your comment moderation queue and delete old internal notifications. Don’t confuse them with customer comments.
A tidy moderation queue means less time sorting junk and more time answering people who may become customers. Preserve useful internal linking so visitors can still discover related content.
Block XML-RPC Only When Your Site Doesn’t Need It
Disabling pingbacks changes a WordPress setting. It doesn’t block the XML-RPC endpoint.
XML-RPC has valid uses. The WordPress mobile app, the Jetpack plugin, and remote publishing tools may depend on it. If you use any of them, blocking the endpoint can break a workflow you rely on.
Check what relies on XML-RPC first
Before you block anything, test your site and list the tools connected to it. Identify whether xmlrpc.php is used by Jetpack features, mobile publishing, external posting tools, or older integrations.
If none depend on XML-RPC, restricting the endpoint removes the path used for pingback requests and multicall login attempts that enable brute-force attacks. It can also reduce reflected traffic involved in some DDoS attacks.
Choose the right protection layer
On Apache hosting, you can block xmlrpc.php through the site’s .htaccess file with a tested code snippet. Follow cPanel’s XML-RPC blocking instructions rather than pasting random rules from an old forum post. Shield Security PRO can also help manage this choice through its plugin settings.
Nginx users need a server level rule, usually added by the hosting provider. A web application firewall can restrict requests to the XML-RPC file, while Shield Security PRO can monitor related activity. Ask your host about the safest server configuration code snippet for your setup.
For a WordPress-level option, the filter add_filter( 'xmlrpc_enabled', '__return_false' ); disables XML-RPC methods. You might place this code snippet in functions.php, but a site-specific plugin is safer for maintainability. Shield Security PRO can provide another WordPress-level option when you don’t want to maintain PHP changes.
A WordPress filter isn’t equivalent to hosting or firewall protection. Server level blocking is stronger when XML-RPC is genuinely unused, because requests are stopped before WordPress loads. Shield Security PRO is an alternative to manually maintained rules, and its monitoring can help confirm whether a block is safe.
Keep a tested code snippet and a recovery plan before changing server settings. Shield Security PRO can help review the change, but layered WordPress security still matters because blocking XML-RPC won’t stop every brute-force attack.
Test the Change and Protect Your Recovery Plan
After making changes, test a regular comment from a logged-out browser or ask someone you trust to comment. Confirm it reaches moderation or publishes normally under your usual settings. If you use Shield Security PRO, review its relevant status and logs.
Test your internal linking by connecting two existing posts. No self-pingbacks should appear. Check Jetpack, the WordPress mobile app, and connected tools if you changed XML-RPC access. Review xmlrpc.php for unintended exposure, but remember this check can’t prove complete protection against brute-force attacks. If you use Shield Security PRO, retest after changing its settings.
Before editing .htaccess or a server configuration code snippet, create a full backup. If you’d rather spend your time on the business, our managed WordPress hosting includes automatic backups, security monitoring, staging, and WordPress support in one place.
Keep the Conversation, Lose the Noise
Pingbacks are optional, and they don’t control your comment section. You can remove automated link notifications while keeping genuine engagement and internal linking intact.
Start with Discussion settings, update older posts, then consider XML-RPC protection only after checking your integrations. For broader WordPress protection, Shield Security PRO is an optional security layer, not a requirement.
FAQ
Will disabling pingbacks turn off WordPress comments?
No. Pingbacks, trackbacks, and regular comments use separate controls. Keep the normal comment option checked in Discussion settings and on individual posts where you want visitor feedback.
Do global Discussion settings update old posts?
No. They apply only to new posts going forward. Use the bulk editor to change ping settings on older posts and pages.
Should every WordPress site block xmlrpc.php?
Not always. Block it when your site doesn’t use the WordPress mobile app, Jetpack features, or remote publishing tools that require XML-RPC. A WordPress-level filter or code snippet may be better than server-level blocking in some setups. Shield Security PRO is another optional protection method, but test its integrations first.
Can self-pingbacks hurt search rankings?
Self-pingbacks don’t directly hurt search rankings. They mainly create moderation clutter. Keep your internal links so visitors can find related content, then block the internal notifications instead.
