How to Completely Disable Comments in WordPress

WordPress makes it easy to stop comments on new posts.

Completely disabling the comment system across an established website is a different task.

Unchecking one option under Settings → Discussion does not necessarily:

• close comments on existing posts;
• remove historical comments;
• remove comment forms from every theme template;
• remove comment-related controls from wp-admin;
• disable pingbacks and trackbacks;
• remove comment support from custom post types;
• remove plugin features built on the WordPress comment system.

A complete implementation therefore requires several separate decisions.

The useful model is:

stop future comments
+
close existing content
+
remove unnecessary comment UI
+
review historical comments
+
review pingbacks and trackbacks
+
audit plugin dependencies
+
test frontend and administration

This guide explains how to completely disable comments in WordPress, including new and existing content, runtime enforcement, post-type support, frontend output, administration interfaces and the existing comments already stored in your database.

First decide what “disable comments” means

There are several levels of comment disabling.

Level 1: disable comments on future posts

new posts
→ closed by default

old posts
→ unchanged

Level 2: close comments everywhere

new posts
→ closed

existing posts
→ closed

existing comments
→ preserved

Level 3: remove comments from the public experience

new submissions
→ disabled

existing forms
→ removed

existing discussions
→ hidden or intentionally retained

Level 4: remove the comment feature from the site workflow

frontend
→ no commenting

edit screens
→ no comment controls

wp-admin
→ comment UI reduced or removed

pingbacks
→ reviewed

historical data
→ intentionally retained or deleted

Most websites that say they want to “completely disable comments” actually mean Level 4.

Step 1: disable comments for new posts

Open:

Settings
→ Discussion

Then disable:

Allow people to submit comments on new posts

The official WordPress Discussion Settings documentation explains that these default article settings can be overridden for individual content.

This changes the default, not necessarily old posts

The important word in the setting is:

new

If your website already contains 800 posts created while comments were enabled, those posts can retain:

comment_status = open

even after you disable the global default.

This distinction is covered in detail in WordPress Per-Post vs. Site-Wide Comment Settings.

Step 2: close comments on existing posts

If the site should stop accepting comments everywhere, existing content must also be reviewed.

WordPress lets you close comments individually or in bulk.

Close comments with Bulk Edit

For normal Posts:

1. Open Posts → All Posts.
2. Select the posts you want to change.
3. Choose Edit from Bulk actions.
4. Click Apply.
5. Set Comments to Do not allow.
6. Click Update.

The official WordPress Comment Moderation documentation documents both individual and bulk comment closing.

Process all relevant pages of content

If the administration list contains multiple pages, selecting everything visible may affect only the currently selected records.

Verify the scope of the operation rather than assuming one bulk action changed the entire database.

Check Pages too

Existing Pages can have their own discussion state.

Review:

Pages
→ All Pages

and close comments where necessary.

Check custom post types

Plugins and themes can register additional content types with comment support.

Examples may include:

• products;
• events;
• courses;
• listings;
• reviews;
• directory entries;
• custom editorial content.

Do not assume that closing comments on Posts and Pages covers every comment-enabled object on the site.

Be especially careful with WooCommerce

Product reviews in WooCommerce are integrated with WordPress’s comment architecture.

If your store uses product reviews, globally disabling the comment system without testing can interfere with functionality that is not presented to visitors as a normal blog comment section.

Before applying site-wide comment restrictions on an e-commerce site, test:

• product reviews;
• review submission;
• rating output;
• review administration;
• structured data generated from reviews.

Do not assume “comments” means only blog discussions

On some WordPress installations, the comment system also supports other forms of user-generated content.

Audit first.

Disable second.

Step 3: enforce comments closed at runtime

If you want an additional site-level enforcement layer, WordPress exposes the:

comments_open

filter.

The official comments_open documentation describes it as filtering whether the current post is open for comments.

Force comments closed

add_filter(
    'comments_open',
    '__return_false',
    20,
    2
);

This makes WordPress report comments as closed during requests affected by the filter.

Understand what this filter does not do

Suppose a post contains:

comment_status = open

in the database.

With the filter active:

stored status
→ open

effective comments_open()
→ false

The filter does not necessarily rewrite the stored post record.

Persistent closure and runtime closure are different

For a long-term configuration, it can be useful to combine:

stored posts closed
+
runtime enforcement

rather than relying exclusively on one layer.

Step 4: disable pingbacks and trackbacks where appropriate

WordPress discussion functionality includes more than visitor comments.

It also includes:

• pingbacks;
• trackbacks;
• self-pingbacks.

Under:

Settings
→ Discussion

review the setting that allows link notifications from other blogs.

Comments and pings have separate states

A WordPress post can store:

comment_status

and:

ping_status

independently.

You can therefore theoretically have:

comments = closed
pings = open

which is probably not what you intend if the objective is to eliminate the entire discussion system.

For the wider distinction, see Pingbacks, Trackbacks & Internal Links.

Existing posts may retain ping settings too

Just as existing posts can retain their old comment status, they can retain their existing ping configuration.

Audit both when implementing a comprehensive policy.

Force pings closed at runtime

WordPress also exposes:

pings_open

as a filterable state.

A complete runtime restriction can include:

add_filter(
    'comments_open',
    '__return_false',
    20,
    2
);

add_filter(
    'pings_open',
    '__return_false',
    20,
    2
);

Step 5: remove comment support from post types

If comments are not part of the editorial workflow at all, you may also want to remove comment support from the relevant post types.

WordPress provides:

remove_post_type_support()

The official remove_post_type_support() documentation states that the comments feature controls comment-related support on the edit interface, including the comment count shown there.

Remove comment support from Posts and Pages

add_action(
    'init',
    function () {
        remove_post_type_support(
            'post',
            'comments'
        );

        remove_post_type_support(
            'page',
            'comments'
        );
    }
);

This improves the editorial interface

If comments are disabled permanently, editors generally do not need comment-related controls on every post-edit screen.

Removing post-type support helps align the editor with the site’s actual policy.

But remove_post_type_support() is not sufficient by itself

This function primarily changes support registered for the post type.

It should not be treated as:

delete comments
+
close every old database record
+
remove every frontend comment template

Those remain separate concerns.

Remove comment support from custom post types carefully

For example:

add_action(
    'init',
    function () {
        $post_types = array(
            'post',
            'page',
            'portfolio',
        );

        foreach ( $post_types as $post_type ) {
            remove_post_type_support(
                $post_type,
                'comments'
            );
        }
    },
    100
);

Only include post types whose comment-dependent functionality you have actually audited.

Do not blindly remove comments support from every public post type

A generic loop over every registered post type can affect:

• product reviews;
• plugin feedback systems;
• membership features;
• other custom workflows.

Explicit configuration is usually easier to understand and safer to maintain.

Step 6: decide what happens to old comments

Closing comments does not normally delete comments that already exist.

For example:

Post
→ comments closed

Existing 42 approved comments
→ remain stored

The complete behavior is explained in What Happens to Old Comments When You Disable Them.

You have three main choices for historical comments

Option 1: keep them visible

new comments
→ disabled

old comments
→ readable

This creates an archived discussion.

Option 2: hide them but preserve the records

new comments
→ disabled

old comments
→ not shown publicly

database records
→ retained

Option 3: delete them

new comments
→ disabled

old comments
→ permanently removed according to deletion policy

Do not delete historical comments merely to disable new ones

Existing discussions may contain:

• useful questions;
• author responses;
• product information;
• corrections;
• community knowledge;
• historical context.

Retention and future-submission policy should be separate decisions.

Hidden comments are still stored data

If you remove historical comments from the frontend but leave them in the database, they may still contain:

• names;
• email addresses;
• website URLs;
• comment text;
• timestamps;
• other comment metadata.

Frontend hiding is not data deletion.

Step 7: review frontend theme output

Closing comments does not automatically guarantee that every comment-related visual element disappears.

A theme may still output:

• existing comments;
• comment counts;
• comment anchors;
• “Comments are closed” messages;
• reply links;
• comment-related headings.

Classic themes commonly use comments_template()

WordPress provides:

comments_template()

The official comments_template() documentation explains that it loads the comments template and queries associated comments.

A common theme pattern preserves historical discussion

A traditional template may use:

if (
    comments_open()
    ||
    get_comments_number()
) {
    comments_template();
}

This means:

new comments closed
+
old comments exist
→ comment template still loads

This can be exactly what you want

If the policy is:

archive discussion
but accept no new replies

then historical comments should continue to render.

If you want no comments visible at all, review the template

The presentation layer may need adjustment so the theme stops loading the comment area.

Do this deliberately rather than deleting comments merely to make them disappear.

Block themes handle presentation differently

Block themes can include comment-related blocks directly inside templates.

You may need to review the relevant template in the Site Editor and remove comment blocks if the entire public comment experience should disappear.

For the architectural difference, see WordPress Comments in Classic vs. Block Themes.

Check comment count links

A theme may display:

17 Comments

on archive cards, post metadata or single templates.

If clicking that link leads to a comments section you intentionally removed, the interface becomes misleading.

Review all frontend comment surfaces

Check:

• single posts;
• Pages;
• archives;
• search results;
• homepage cards;
• sidebars;
• footer widgets;
• custom post-type templates;
• mobile layouts.

Step 8: review the WordPress admin menu

Even after comments are closed, WordPress may still expose the Comments administration screen because historical comments continue to exist.

If comments are completely outside the site’s workflow, you may want to simplify the interface.

Remove the Comments menu item

A site-specific implementation can use:

add_action(
    'admin_menu',
    function () {
        remove_menu_page(
            'edit-comments.php'
        );
    }
);

Hiding the menu is not permission enforcement

This code changes navigation.

It should not be interpreted as an authorization layer.

The distinction is:

remove_menu_page()
→ hide navigation

capabilities
→ control authorization

Decide whether administrators still need access

If historical comments are being retained for moderation or reference, removing the Comments menu for every administrator may be counterproductive.

A role-aware configuration may make more sense.

Step 9: remove the Dashboard comment-related widget if appropriate

The WordPress Dashboard Activity widget can include recent comment information.

If comments are permanently disabled and the Activity widget no longer provides useful information, review whether it should remain.

Dashboard cleanup is covered in How to Remove Widgets from the WordPress Dashboard.

Do not remove Activity automatically

The widget also contains other activity information.

Evaluate whether it remains useful instead of deleting it simply because comments are gone.

Step 10: remove comment controls from the admin bar where necessary

The WordPress toolbar can contain a Comments item for users with appropriate permissions.

If comments have been removed from the site workflow, leaving a comment shortcut in the toolbar creates unnecessary navigation.

Review toolbar controls as part of the overall administration cleanup.

Step 11: review comment feeds

WordPress supports comment-related feeds.

If comments remain publicly visible as an archive, keeping historical comment feed behavior may or may not be desirable.

If the goal is:

no public discussion surfaces

audit feed behavior separately.

Do not assume closing comments automatically removes every feed URL

Comment availability and feed routing are separate parts of WordPress.

If feed removal is part of your policy, implement and test it explicitly.

Step 12: audit REST API behavior

Modern WordPress functionality also exposes comment data and operations through API infrastructure where permitted.

A complete comment-removal audit should therefore include whether plugins, applications or frontend JavaScript rely on WordPress comment endpoints.

Do not disable the entire REST API just to solve comments

The REST API is used by many WordPress features and plugins.

If comment-related API access requires restriction, target the relevant behavior rather than disabling unrelated REST functionality.

This is consistent with the broader principle explained in What Depends on the WordPress REST API.

Step 13: audit XML-RPC, pingbacks and remote discussion behavior separately

WordPress XML-RPC and the comment system overlap in areas such as pingbacks, but they are not synonymous.

Disabling visitor comments does not mean:

XML-RPC disabled

and disabling XML-RPC does not mean:

normal comments disabled

For more context, see XML-RPC in WordPress, Explained.

Do not solve the wrong subsystem

Keep these concepts separate:

normal comments
→ visitor discussion

pingbacks / trackbacks
→ link notifications

XML-RPC
→ remote publishing/API protocol with additional functions

REST API
→ modern application interface

Step 14: stop comment spam at the source

If the website does not need comments, preventing submissions is cleaner than continuously moderating spam for a feature nobody uses.

Spam can otherwise produce:

• database rows;
• comment metadata;
• moderation workload;
• notification email;
• background processing.

This is particularly useful for sites that accumulated comment spam simply because the default WordPress discussion system remained active.

Old spam does not disappear automatically

After disabling comments, previously stored spam remains until cleaned.

A website can therefore have:

comments completely disabled
+
50,000 old spam records

Those are separate problems.

Review the database after disabling comments

Once the site is no longer accepting comments, audit:

• approved historical comments;
• pending comments;
• spam;
• Trash;
• comment metadata.

Do not automatically delete valuable historical discussion together with disposable spam.

The comment database tables

WordPress stores core comment information primarily in:

wp_comments
wp_commentmeta

Your actual prefix may differ from:

wp_

Do not empty these tables casually

Comments may be used by plugins or product-review systems.

Deleting the tables or blindly truncating them can destroy data beyond ordinary blog comments.

Use WordPress administration or APIs for intentional deletion

WordPress provides:

wp_delete_comment()

for programmatic comment deletion.

The administrative Comments screen also supports bulk moderation and deletion.

Back up before large-scale deletion

Before deleting thousands of historical comments:

• create a current database backup;
• verify that the backup contains comment tables;
• confirm that it can be restored;
• identify plugin dependencies;
• test the cleanup on staging.

Do not delete wp-comments-post.php

Older WordPress advice sometimes recommends physically deleting:

wp-comments-post.php

or modifying Core files.

That is not a maintainable method for modern WordPress administration.

Core files should remain intact

WordPress updates expect the normal Core file structure.

Use:

• settings;
• hooks;
• filters;
• post-type support;
• plugins;
• site-specific code.

instead of modifying or deleting WordPress Core.

Do not use CSS as the primary disabling method

This:

.comments-area {
    display: none;
}

only changes presentation.

It does not necessarily prevent:

• comment submission;
• database storage;
• API access;
• admin access;
• spam attempts.

Hiding the form and disabling the system are different things

The correct direction is:

disable functionality first
↓
clean presentation second

Do not rely only on removing comments_template()

If a theme stops calling:

comments_template()

the frontend discussion may disappear.

That does not necessarily change:

comment_status

or prevent other submission paths.

A robust custom implementation

For a standard content website where Posts and Pages should never use comments or pings, a site-specific implementation could include:

/**
 * Disable comments and pingbacks at runtime.
 */
add_filter(
    'comments_open',
    '__return_false',
    20,
    2
);

add_filter(
    'pings_open',
    '__return_false',
    20,
    2
);


/**
 * Remove comment support from standard content types.
 */
add_action(
    'init',
    function () {
        remove_post_type_support(
            'post',
            'comments'
        );

        remove_post_type_support(
            'post',
            'trackbacks'
        );

        remove_post_type_support(
            'page',
            'comments'
        );

        remove_post_type_support(
            'page',
            'trackbacks'
        );
    },
    100
);

This still does not delete old comments

The snippet controls ongoing functionality and editor support.

Historical comments remain a separate retention decision.

Optional: hide existing comments from theme queries

WordPress provides the:

comments_array

filter over comments supplied to the comments template.

The official comments_array documentation confirms that it filters the comment collection passed to the template.

If you intentionally need existing comments hidden while retaining database records, frontend rendering can be altered.

However, hiding via this layer should be treated as presentation policy rather than data deletion.

Do not hide historical comments without understanding the UX

If the theme still outputs:

23 Comments

while the actual comment list is filtered away, visitors receive inconsistent information.

Review counts, anchors and related UI at the same time.

Where should custom comment-disabling code live?

Suitable locations include:

• a site-specific plugin;
• a must-use plugin;
• a maintained snippet manager.

For a permanent site policy, functionality is usually better kept outside the active theme.

Why theme-only code can be fragile

If disabling comments exists only in:

functions.php

then changing themes can restore the comment behavior unexpectedly.

A site-wide content policy is usually independent of visual design.

What about WordPress Multisite?

In Multisite, comment settings and content exist at the individual site level.

Do not assume changing one site automatically configures every other site in the network.

Audit each relevant site or deploy a controlled network-wide implementation where appropriate.

What happens if you enable comments again later?

The answer depends on how comments were disabled.

If you only used a runtime filter

Removing the filter may expose the stored post statuses again.

If you permanently closed existing posts

Those posts remain:

comment_status = closed

until changed again.

If you removed post-type support

Restoring support can bring editor controls back, but stored states still matter.

If you deleted historical comments

They do not return merely because comments are re-enabled.

This is why implementation choice matters

Before disabling comments, decide whether the policy is:

temporary
or
permanent

and whether historical discussion should remain recoverable.

Using TheOneWP Disable Comments

If comments are not part of the website’s workflow at all, TheOneWP Disable Comments provides a dedicated module for disabling WordPress comment functionality.

The module is intended for sites where keeping an unused comment system active would only add unnecessary interface and activity.

A dedicated control can be preferable to scattering multiple unrelated snippets across a theme and several plugins.

Still audit plugin dependencies first

Even when using a dedicated module, check whether the site relies on comments for:

• WooCommerce reviews;
• custom reviews;
• ratings;
• discussion tools;
• plugin workflows.

A global comment policy should be intentional.

Complete comments-disable audit

Before considering the task finished, review all of the following.

New content

• Is the site-wide default set to closed?
• Does a newly created Post start with comments disabled?
• Does a newly created Page behave as expected?

Existing content

• Are old Posts closed?
• Are old Pages closed?
• Are comment-enabled custom post types reviewed?

Runtime behavior

• Does comments_open() return false where expected?
• Are pingbacks also closed if required?
• Are plugins overriding the status?

Frontend

• Is the comment form absent?
• Are reply links gone?
• Are comment-count links still useful?
• Are historical comments shown or hidden according to policy?
• Are block-theme templates clean?
• Are classic theme templates clean?

Administration

• Are unnecessary Discussion controls removed from post types?
• Should the Comments menu remain?
• Should comment toolbar items remain?
• Should comment-related Dashboard information remain?

Historical data

• Should approved comments be retained?
• Should pending comments be processed?
• Should spam be deleted?
• Should Trash be emptied?
• Is comment metadata still required?

Integrations

• Do WooCommerce reviews still work if required?
• Do other plugins use WordPress comments?
• Are REST integrations affected?
• Are XML-RPC or pingback policies configured separately?

Test the final configuration while logged out

Administration screens alone do not prove that the public experience is correct.

Open representative content in a private browser session.

Test:

• a recent Post;
• an old Post with historical comments;
• a Page;
• a custom post type;
• a product if WooCommerce is installed;
• mobile layouts.

Try to submit a comment

If the site policy is:

comments completely disabled

there should not be a normal public workflow that successfully creates a new comment.

Check direct and alternative entry points

Testing should include more than whether the form is visible.

Review:

• standard frontend forms;
• plugin-generated forms;
• custom integrations;
• API-dependent functionality.

Purge caches after changing comment behavior

Full-page caches can temporarily preserve old HTML containing:

• comment forms;
• reply links;
• comment counts;
• discussion sections.

Purge relevant caches before diagnosing the final state.

Test on staging before applying broad changes

This is particularly important when the website contains:

• many years of comments;
• WooCommerce;
• custom post types;
• membership features;
• third-party applications.

See WordPress Staging Site Best Practices.

Common mistakes when disabling comments

Changing only Settings → Discussion

This can leave comments open on old content.

Closing old posts but leaving future defaults open

New posts can then start accepting comments again.

Deleting comments unnecessarily

Closing discussion does not require erasing historical data.

Hiding comments only with CSS

Presentation is not functionality.

Removing the comments template only

This can hide discussion without actually closing submissions elsewhere.

Forgetting pingbacks

Normal comments and pings are separate states.

Forgetting custom post types

Plugins can register additional comment-enabled content.

Breaking WooCommerce reviews

Product reviews must be audited before aggressive global removal.

Editing WordPress Core

Use supported settings and APIs rather than modifying Core files.

Deleting database tables

The comment tables may contain data required by other features.

Removing admin navigation and assuming that secures anything

Menu visibility is not authorization.

Testing only as Administrator

Test the public site and all relevant user workflows.

Forgetting cache

A stale page can make a correct configuration appear broken.

Complete WordPress comments-disable checklist

• Define whether the policy is temporary or permanent.
• Decide whether historical comments should remain visible.
• Decide whether historical comments should remain stored.
• Disable comments for new posts under Settings → Discussion.
• Close comments on existing Posts.
• Close comments on existing Pages where required.
• Audit custom post types.
• Audit WooCommerce product reviews.
• Audit other review or rating systems.
• Review comment_status on existing content.
• Consider runtime enforcement through comments_open.
• Review pingbacks and trackbacks.
• Consider runtime enforcement through pings_open.
• Remove comment post-type support where appropriate.
• Remove trackback support where appropriate.
• Review classic theme comment templates.
• Review block theme comment templates.
• Remove unused comment forms.
• Remove misleading reply links.
• Review comment-count links.
• Review comment archives and historical display.
• Review comment feeds.
• Review REST-dependent integrations.
• Review XML-RPC and pingback behavior separately.
• Review the Comments admin menu.
• Review Dashboard comment information.
• Review admin-toolbar comment links.
• Process pending comments.
• Clean unwanted spam.
• Review Trash.
• Review comment metadata before deletion.
• Create a verified backup before bulk deletion.
• Do not modify WordPress Core files.
• Do not rely on CSS as a disabling mechanism.
• Do not truncate comment tables without an audit.
• Place permanent site policy in site-level functionality.
• Test on staging first.
• Test new content.
• Test existing content.
• Test content with historical comments.
• Test custom post types.
• Test e-commerce functionality.
• Test while logged out.
• Purge caches.
• Re-test after major WordPress or plugin updates.

Related guides

• WordPress Per-Post vs. Site-Wide Comment Settings
• What Happens to Old Comments When You Disable Them
• WordPress Comments in Classic vs. Block Themes
• Pingbacks, Trackbacks & Internal Links
• XML-RPC in WordPress, Explained
• WordPress Staging Site Best Practices

Final recommendation

Completely disabling comments in WordPress should be treated as a site policy, not as a single checkbox.

If comments are genuinely unnecessary, configure every relevant layer deliberately.

The basic sequence should be:

disable future comments
↓
close existing content
↓
review pingbacks and trackbacks
↓
remove unnecessary post-type support
↓
decide what happens to historical comments
↓
clean frontend comment UI
↓
clean unnecessary admin UI
↓
audit plugin dependencies
↓
test all relevant content types

Do not delete historical discussion merely because new comments are no longer wanted.

Do not hide a form and assume submissions are impossible.

Do not remove an admin menu and assume the underlying feature has disappeared.

Do not disable unrelated systems such as the entire REST API simply because comments use part of WordPress’s broader API architecture.

And do not apply global restrictions without checking whether product reviews or another plugin depend on comments.

The clean separation is:

Settings
→ future defaults

comment_status
→ stored state for each post

comments_open
→ effective runtime state

post-type support
→ editorial interface

theme templates
→ frontend presentation

comment records
→ historical data

ping_status
→ pingback / trackback state

Once those layers are addressed intentionally, WordPress comments can be removed from the site’s workflow without leaving half-enabled forms, forgotten old posts or unnecessary administration clutter behind.