What Happens to Old Comments when you Disable Them

Disabling comments in WordPress does not necessarily delete the comments that already exist.

This distinction is important because WordPress treats several related actions separately:

stop accepting new comments
≠
hide existing comments
≠
delete existing comments
≠
remove the comment system entirely

You can close comments on a post while keeping every previously approved discussion visible.

You can also hide comments in a theme while the comment records remain stored in the database.

And changing the global Discussion setting does not automatically rewrite the comment status of every post that already exists.

This guide explains what happens to old WordPress comments when comments are disabled, how site-wide and per-post settings interact, what remains in the database, what visitors can still see and what you should do if you want comments closed, hidden or permanently deleted.

The short answer

In most normal WordPress configurations:

Disable new comments
↓
existing comments remain stored
↓
approved comments can remain visible
↓
new submissions are prevented

Disabling comments is therefore usually a change to whether future discussion is allowed.

It is not automatically a deletion operation.

WordPress comments have several separate states

To understand the behavior correctly, separate these concepts:

• whether a post accepts new comments;
• whether existing comments are approved;
• whether the theme displays existing comments;
• whether the comments still exist in the database;
• whether comment administration screens remain available.

Those layers can behave independently.

Closing comments does not normally delete them

Suppose a post currently contains:

24 approved comments

You then change the post so comments are closed.

The expected result is generally:

24 approved comments
→ remain

new comment form
→ closed or unavailable

The historical discussion remains associated with the post.

Old comments are stored separately from the post’s comment status

WordPress stores a post’s comment availability through its post data.

The relevant field is:

comment_status

Typical values are:

open
closed

The existing comments themselves are stored separately in WordPress’s comments system.

Changing comment_status does not erase comment records

Conceptually:

wp_posts
↓
comment_status = closed

wp_comments
↓
existing comment records remain

This separation is why WordPress can display a historical discussion even though no new replies are accepted.

What happens when you disable comments in Settings → Discussion?

WordPress includes the setting:

Allow people to submit comments on new posts

under:

Settings
↓
Discussion

The official WordPress Discussion Settings documentation explains that this setting controls the default discussion behavior for new content.

The important word is “new”

Turning this option off does not necessarily close comments on all posts that already exist.

A simplified timeline looks like:

2024
Post A created
comments enabled

2025
Post B created
comments enabled

2026
global default changed
comments disabled

New Post C
→ comments disabled by default

Old Post A
→ may still be open

Old Post B
→ may still be open

This behavior is one of the most common sources of confusion when disabling comments.

Existing posts preserve their own discussion status

WordPress stores whether comments are open or closed for individual posts.

Changing the global default therefore does not necessarily rewrite every existing record.

For the broader distinction, see WordPress Per-Post vs. Site-Wide Comment Settings.

This is why spam can continue after changing Discussion Settings

An administrator may disable:

Allow people to submit comments on new posts

and then discover that old articles still receive comments.

That does not necessarily mean the setting failed.

It may simply mean:

new default
→ closed

existing posts
→ still open

You need to close comments on existing content separately

If the objective is:

no new comments anywhere

you should also review existing posts and pages.

For the complete site-wide process, see How to Completely Disable Comments in WordPress.

What happens when you close comments on one existing post?

Assume:

Post A
100 approved comments
comment_status = open

You change it to:

comment_status = closed

The normal result is:

existing 100 comments
→ remain stored

existing 100 comments
→ can remain visible

comment form
→ unavailable

new standard submissions
→ rejected

comments_open() reflects whether new comments are accepted

WordPress provides:

comments_open()

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

Conceptually:

comments_open()
→ may visitors submit another comment?

It does not answer:

are there already comments?

Existing comment count is a separate question

WordPress provides:

get_comments_number()

to retrieve the number of comments associated with a post.

A theme can therefore encounter:

comments_open() = false

get_comments_number() = 37

That is a perfectly valid state.

A well-designed theme should account for that state

A common template condition is conceptually:

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

This means:

comments open
→ show discussion area

OR

old comments exist
→ still show discussion area

Why this matters

If a theme uses only:

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

then closing comments may accidentally hide the entire comments section, including historical comments.

The comments would still exist in WordPress.

The theme would simply stop rendering them.

Hidden is not deleted

This distinction deserves special attention.

You can have:

37 comments in database
+
0 comments shown on frontend

if the theme or plugin decides not to display them.

Check the administration area before assuming comments are gone

If comments disappear from the frontend after you disable commenting, open:

Dashboard
↓
Comments

If the old comments remain there, they were probably not deleted.

The issue is likely one of:

• theme rendering;
• block-template configuration;
• plugin behavior;
• comment-query filtering.

Classic themes control comments through templates

Traditional WordPress themes usually use:

comments_template()

to load their comment template.

The template may display:

• existing comments;
• pagination;
• the comment form;
• closed-discussion messaging.

Block themes use a different presentation system

Modern block themes can manage comment presentation through blocks and templates rather than the traditional PHP structure alone.

The difference is covered in WordPress Comments in Classic vs. Block Themes.

Disabling comments does not automatically remove comment blocks

A block theme may still contain blocks responsible for rendering existing discussion.

Closing comments affects whether new discussion is accepted.

Template composition determines whether historical discussion appears.

Automatically closing old comments also preserves existing comments

WordPress includes another Discussion setting:

Automatically close comments
on articles older than X days

The official WordPress documentation explains that this setting prevents new comments after the specified age while leaving previously approved comments visible.

Example

Suppose you configure:

Automatically close comments
after 30 days

A post reaches day 31.

The normal intended behavior becomes:

existing discussion
→ remains

new comment form
→ unavailable

This is useful for preserving historical conversations

For example, a news publication may want:

first 30 days
→ active discussion

after 30 days
→ archived discussion

The existing conversation remains useful context even though new replies are no longer accepted.

Does disabling comments delete pending comments?

No, merely closing comments does not normally delete pending comments that already exist.

A comment can have a moderation status independently of whether the post currently accepts new comments.

Previously submitted comments may therefore still exist as:

• approved;
• pending;
• spam;
• Trash.

Closing comments and moderating comments are separate actions

Think of it as:

comment_status
→ can new comments arrive?

comment moderation status
→ what happens to comments already stored?

Does disabling comments empty Spam?

No.

Comments already classified as spam remain comment records until they are deleted according to your administration workflow or cleanup behavior.

Disabling future submissions does not transform:

Spam
→ empty

Does disabling comments empty Trash?

No.

Comments in Trash remain separate from the open or closed status of the associated post.

Does disabling comments remove comment counts?

Not necessarily.

If a post has approved comments, its comment count can remain greater than zero even though comments are closed.

WordPress maintains comment counts separately from whether discussion is open.

Your theme may still show “12 Comments”

A closed article can still display:

12 Comments

because twelve approved comments still exist.

That is expected.

Closing comments does not make old discussions private

If historical comments remain rendered publicly, disabling new comments does not restrict access to them.

Visitors can continue reading the existing discussion.

If your objective is:

comments should no longer
be publicly visible

that is a separate requirement.

You can preserve comments without displaying them

Some sites want to stop displaying discussion while keeping the records for:

• historical reasons;
• future migration;
• administrative reference;
• legal or moderation records;
• possible later restoration.

In that case you can:

keep database records
+
stop frontend rendering

Do not delete comments when hiding is sufficient

Deletion may be irreversible once backups and retention periods move forward.

If you are uncertain whether the historical discussion will be needed later, hiding can preserve more options.

But hidden comments still exist as stored data

This matters for privacy and data-retention policies.

A hidden comment may still contain:

• author name;
• email address;
• website URL;
• IP-related metadata depending on collection and configuration;
• comment text;
• timestamps.

Removing comments from the frontend does not itself erase that stored information.

Deletion is a different operation

If you intentionally delete an existing comment, WordPress performs a separate comment deletion process.

The relevant API includes:

wp_delete_comment()

The official wp_delete_comment() documentation covers programmatic comment deletion.

Do not confuse closing with deletion

The difference is:

CLOSE COMMENTS

existing comment record
→ remains

future submission
→ prevented


DELETE COMMENT

existing comment record
→ removed according to deletion behavior

You can delete comments manually from wp-admin

Open:

Comments

and manage comments individually or in bulk.

This allows you to decide whether historical discussion should:

• remain approved;
• move to Trash;
• be marked as spam;
• be permanently deleted.

Do not bulk-delete comments merely because you are disabling future discussion

The two decisions should be independent.

Ask:

Do we want people
to keep commenting?

and separately:

Do we want to preserve
the existing conversation?

When should old comments usually be preserved?

Preservation can make sense when comments contain:

• useful questions and answers;
• community discussion;
• historical context;
• product feedback;
• author clarifications;
• valuable corrections.

When might deletion make sense?

Deletion may be appropriate when old comments are:

• spam;
• abusive;
• obsolete test data;
• unwanted personal information;
• content the site no longer has a reason to retain.

The decision should reflect moderation, privacy and retention requirements rather than simply whether future commenting remains enabled.

What happens to replies and threaded comments?

Closing discussion does not normally flatten or delete existing comment threads.

A historical thread can remain:

Comment A
└── Reply B
    └── Reply C

while the post no longer accepts another reply.

The reply UI should disappear when discussion is closed

A properly implemented comments template should not invite new replies when WordPress reports that commenting is closed.

If a theme continues displaying a functional-looking reply form, inspect its implementation.

Can administrators still edit old comments?

Closing public commenting does not generally prevent authorized WordPress users from managing existing comment records in wp-admin.

Administrators and other appropriately permitted users can still perform moderation tasks according to their capabilities.

Can you reopen comments later?

Yes.

Because closing comments does not normally delete the existing discussion, reopening them can resume the same thread.

For example:

2025
comments open
→ 18 comments received

2026
comments closed
→ existing 18 preserved

later
comments reopened
→ discussion can continue

This is one reason not to delete historical comments unnecessarily

If you might later restore commenting, retaining the discussion preserves continuity.

Disabling comments globally through code can behave differently

Developers can also filter:

comments_open

The official comments_open filter allows code to override whether comments appear open for a post.

For example:

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

This does not necessarily rewrite post records

A filter can make WordPress behave as though comments are closed during the request while the underlying post’s stored comment_status remains unchanged.

That distinction becomes important if the filter is later removed.

Runtime filtering vs stored status

Consider:

Database:
comment_status = open

Runtime filter:
comments_open = false

Result:
site behaves as closed

Remove the filter and the stored post state may become relevant again.

Bulk-closing existing comments changes stored post state

By contrast, updating existing posts to:

comment_status = closed

changes their persistent configuration.

That can be preferable when the site’s long-term policy is genuinely:

these posts no longer
accept discussion

Use WordPress bulk editing for existing content

If many posts need their discussion status changed, the WordPress Posts screen provides bulk editing.

A typical workflow is:

1. Open Posts → All Posts.
2. Select the relevant posts.
3. Choose Edit from Bulk actions.
4. Apply the action.
5. Change Comments to Do not allow.
6. Save the bulk edit.

Check more than Posts

Comments may be supported by:

• Posts;
• Pages;
• custom post types;
• products;
• events;
• other plugin-defined content.

A complete site audit needs to identify every public post type where discussion is enabled.

Custom post types can support comments

When a custom post type is registered with comment support, its records can participate in the same WordPress comment system.

Do not assume:

Settings → Discussion changed
↓
every custom content type closed

Inspect them independently.

Comments and pingbacks are related but not identical

WordPress’s discussion architecture also includes:

• pingbacks;
• trackbacks;
• internal self-pingbacks.

Disabling normal visitor comments does not automatically answer every question about those mechanisms.

See Pingbacks, Trackbacks & Internal Links for that broader distinction.

Comment spam can remain in the database after comments are disabled

If the site accumulated thousands of spam comments before discussion was closed, those rows do not disappear merely because future comments are blocked.

They still need normal spam-management or deletion processes.

The website field can be a spam target

One reason spam bots target WordPress comments is the potential value of comment-author URLs and automated link placement.

For more context, see Why Comment Spam Targets the Website Field.

Should you remove comment counts after disabling comments?

Usually not automatically.

If historical comments remain visible, showing:

42 Comments

can still be useful.

If comments are intentionally hidden from the frontend, displaying a comment count that leads nowhere may be confusing.

Presentation should match your policy

If your policy is:

discussion archived but readable

then keeping:

• comment counts;
• historical comments;
• comment anchors;

can make sense.

If your policy is:

comments completely removed
from public experience

then remove related frontend UI consistently.

Check theme templates after changing comment policy

Review:

• single-post templates;
• page templates;
• archive comment counts;
• comment links;
• comment navigation;
• reply links;
• sidebar widgets;
• block templates.

Do not leave broken comment links

A theme may still output:

<a href="#comments">
    12 Comments
</a>

while the comments section itself has been removed from the template.

That creates a poor user experience.

Comment feeds may also remain relevant

WordPress has feed functionality associated with comments.

If your objective is complete removal of discussion-related public surfaces, comment feeds should be reviewed separately rather than assumed to disappear automatically.

Disabling comments does not necessarily remove comment administration

You may still see:

Comments

in wp-admin because existing comments remain manageable.

A plugin or custom implementation that completely removes the comment feature can go further and remove administration interfaces as well.

Complete comment disabling is broader than closing posts

A comprehensive implementation may address:

• new post defaults;
• existing post statuses;
• comment forms;
• comment frontend output;
• comment administration menus;
• Dashboard widgets;
• REST-related comment functionality where relevant;
• feeds;
• pingbacks and trackbacks.

That is why simply unchecking one Discussion option should not be described as “completely disabling comments.”

For a dedicated procedure, see How to Completely Disable Comments in WordPress.

How TheOneWP handles comment disabling

TheOneWP Disable Comments provides a dedicated way to control WordPress comment functionality.

This is useful when the site’s intended policy is broader than simply changing the default Discussion setting for future posts.

Existing comments still require an explicit retention decision

When disabling comments site-wide, decide separately what should happen to historical discussion.

Possible policies include:

Policy 1: archive and display

new comments
→ disabled

old comments
→ visible

database records
→ retained

Policy 2: archive but hide

new comments
→ disabled

old comments
→ hidden from frontend

database records
→ retained

Policy 3: remove completely

new comments
→ disabled

old comments
→ deleted

frontend discussion
→ removed

There is no universal correct policy

The appropriate choice depends on:

• the value of historical discussions;
• privacy requirements;
• legal retention obligations;
• site purpose;
• moderation burden;
• future plans.

Back up comments before bulk deletion

If you are considering permanent deletion of a large comment history, make a verified backup first.

Deletion is substantially more consequential than closing comments.

Do not rely on a backup you have never tested

A backup file is useful only if:

• it actually contains the relevant database data;
• it can be restored;
• you know where it is;
• its retention period is sufficient.

Test changes on staging when the comment archive is important

If a site has years of discussion history, reproduce the configuration in staging before making large-scale changes.

See WordPress Staging Site Best Practices.

Verify frontend behavior after disabling comments

Check representative content while logged out.

For each page, verify:

• historical comments still appear if intended;
• the comment form is gone if comments are closed;
• reply links are not misleading;
• comment counts remain accurate;
• pagination still works;
• mobile layouts still render properly.

Verify administration behavior too

Inside wp-admin, confirm:

• old comments remain accessible if being preserved;
• pending comments can still be moderated;
• spam can still be cleaned;
• Trash behaves as expected;
• existing posts actually have the intended comment status.

Check a newly created post

After changing the global Discussion default, create a new test post.

Confirm:

new post
→ comments closed by default

Then check an old post

Open a post published before the setting change.

Confirm:

old post
→ comment status matches intended policy

Do not assume the global change retroactively updated it.

Check a post that already has comments

This is the most important historical test.

Verify:

old post
+
existing comments
+
comments closed

and confirm whether:

• the discussion remains visible;
• new submissions are blocked;
• the theme still renders the section correctly.

Check comment-related caching

After changing comment configuration, a page cache may temporarily serve an older page containing:

• a comment form;
• old counts;
• previous markup.

Purge relevant caches before concluding that the configuration failed.

A practical decision tree

Do you want new comments?
│
├── Yes
│   └── keep comments open
│
└── No
    │
    ├── Should old comments remain visible?
    │   │
    │   ├── Yes
    │   │   └── close new comments
    │   │       but keep rendering history
    │   │
    │   └── No
    │       │
    │       ├── Need to preserve records?
    │       │   ├── Yes → hide/archive
    │       │   └── No → consider deletion
    │       │
    │       └── remove related frontend UI

Common mistakes when disabling comments

Assuming Discussion Settings change every old post

The default for new posts and the stored status of existing posts are separate concerns.

Assuming closing comments deletes them

Existing comment records normally remain.

Assuming hidden comments are deleted

A theme can stop rendering comments while they remain in the database.

Deleting useful discussion unnecessarily

Historical comments can contain valuable information that cannot easily be reconstructed later.

Leaving the comment form visible

The interface should not invite an action WordPress no longer accepts.

Leaving comment-count links that lead nowhere

If comments are hidden completely, related navigation should also be reviewed.

Forgetting old custom post types

Discussion may still be enabled outside normal blog posts.

Ignoring spam already stored

Closing future comments does not clean historical spam.

Confusing pingbacks with normal comments

They belong to the broader discussion system but require separate policy decisions.

Testing only while logged in

Always verify the final public behavior as a normal visitor.

Old comments after disabling WordPress comments checklist

• Decide whether you want to stop only new comments or remove comments completely.
• Review Settings → Discussion.
• Understand that the new-post default is not necessarily retroactive.
• Audit existing post comment statuses.
• Audit Pages separately.
• Audit custom post types.
• Bulk-close existing discussion where necessary.
• Confirm existing approved comments remain stored if you want to preserve them.
• Check pending comments.
• Check spam comments.
• Check Trash.
• Decide whether historical comments should remain visible.
• Check theme comment templates.
• Check block-theme comment blocks.
• Verify comment counts.
• Verify comment pagination.
• Remove misleading reply controls.
• Remove misleading comment-form markup.
• Review comment feeds if disabling discussion completely.
• Review pingbacks and trackbacks separately.
• Do not use frontend hiding as a substitute for deleting data when deletion is required.
• Do not delete historical comments when preservation is desired.
• Review privacy and retention requirements.
• Create a verified backup before large-scale deletion.
• Test changes on staging when the archive is important.
• Purge caches after changing comment behavior.
• Test a newly created post.
• Test an old post without comments.
• Test an old post with comments.
• Test logged-out frontend behavior.
• Verify administration access to retained comments.

Related guides

• How to Completely Disable Comments in WordPress
• WordPress Per-Post vs. Site-Wide Comment Settings
• WordPress Comments in Classic vs. Block Themes
• Why Comment Spam Targets the Website Field
• Pingbacks, Trackbacks & Internal Links
• WordPress Staging Site Best Practices

Final recommendation

Disabling comments in WordPress should begin with a clear decision about what you actually want to disable.

There are at least three separate questions:

Should visitors be able
to submit new comments?

Should historical comments
remain publicly visible?

Should historical comment
records remain stored?

Do not treat those as the same decision.

If you simply want to stop future discussion, close comments and preserve the existing archive.

If you want a comment-free frontend but may need the historical records later, hide the discussion while retaining the data.

If the comments themselves should no longer exist, perform an intentional deletion process after reviewing backup, privacy and retention requirements.

Also remember that changing the default Discussion setting for new posts does not necessarily close comments on every existing post.

Audit the stored status of older content separately.

The useful model is:

global Discussion default
→ future content defaults

per-post comment_status
→ whether that post accepts discussion

theme or block template
→ whether old comments are shown

comment database records
→ whether historical comments still exist

Keeping these layers separate prevents accidental deletion and makes WordPress comment management considerably more predictable.

In most cases, the safest sequence is:

decide policy
↓
disable new discussion
↓
close existing posts where required
↓
preserve or remove historical comments intentionally
↓
clean related frontend UI
↓
test old and new content

Closing a conversation and erasing the conversation are not the same operation, and WordPress gives you enough control to choose between them deliberately.