If you want to disable comments on old WordPress posts without deleting the discussion that is already there, start with WordPress’s built-in age rule. Go to Settings → Discussion, enable Automatically close comments on articles older than X days, choose the cutoff, and save. WordPress stops accepting new comments on posts older than that threshold while leaving previously approved comments visible.
That distinction matters: disabling comments is a state change; deleting comments is content destruction. If the job is “stop new comments on our archive,” there is normally no reason to empty wp_comments, truncate tables, or erase legitimate conversation.
The quick answer: five ways to disable comments on old WordPress posts
| Situation | Best method | Plugin? | Existing comments preserved? |
|---|---|---|---|
| Automatically close discussion after posts age | 1. Native age rule | No | Yes |
| Close selected existing posts or pages | 2. Bulk Edit | No | Yes |
| Close large or repeatable batches with shell access | 3. WP-CLI | No | Yes |
| Enforce an ongoing no-comments policy | 4. Disable Comments plugin | Yes | Usually |
| Close everything before an exact date at database scale | 5. Direct SQL | No | Yes, if you only change post state |
The native methods come first on purpose. Adding a permanent plugin for a one-time checkbox job creates another dependency to maintain. Direct SQL sits last because it is powerful and precise, but it bypasses the normal WordPress application path. Powerful does not automatically mean better. Sometimes it just means the mistake happens faster.
Close, hide, and delete are three different jobs
The Scope Design Comment Shutdown Ladder keeps the operations separate:
- Close: stop new comment submissions while approved history can remain visible. This is the default recommendation.
- Hide: change what visitors see. The data can still exist, and hiding a form is not the same as changing whether WordPress accepts comments.
- Delete: remove comment data. This is a separate cleanup or retention decision and deserves its own backup and approval.
Before any large WP-CLI or database change, protect a recovery point and preview what will be affected. That is the same controlled-change discipline in our safe WordPress plugin update guide: know the scope, have a way back, make the smallest necessary change, then prove the result.
Method 1: automatically close comments after X days
Best for: sites that want discussion on fresh articles but want old content to close automatically.
In Settings → Discussion → Other comment settings, enable Automatically close comments on articles older than X days. Enter the age threshold that fits your publishing model—30, 60, 90, 180, or another number—and save. WordPress’s Discussion settings documentation explicitly says the setting prevents new comments after the period while leaving previously approved comments visible.
This is different from unchecking Allow people to post comments on new articles. That option controls the default for new content going forward. The age rule is the built-in answer when you specifically need to disable comments on old WordPress posts.
Custom post types need a separate check
WordPress core’s old-post closure logic defaults to the standard post post type. The core reference for _close_comments_for_old_posts() shows the default and the close_comments_for_post_types filter developers can use to extend it. Do not assume the dashboard age rule automatically covers products, events, portfolios, or every custom post type.
That matters because features can use comments under the hood. WooCommerce product reviews are an obvious example. Inventory the content types before applying a broad rule.
Method 2: Bulk Edit selected existing posts
Best for: a one-time batch where you know which existing posts or pages should stop accepting comments.
- Go to Posts → All Posts.
- Use date, category, author, or search filters to narrow the list.
- Select the posts and choose Bulk actions → Edit.
- Set Comments to Do not allow.
- Click Update and verify representative posts on the front end.
WordPress’s Posts screen documentation confirms that Bulk Edit can change Comments Allowed for selected posts. The same general approach is available for Pages.
Some tutorials call 20 posts a hard Bulk Edit limit. It is not. Twenty is a common default number of rows shown in the admin list. You can display more rows and work in sensible batches. On large sites, smaller batches are often smarter because they make failures easier to isolate.
Method 3: WP-CLI for large or repeatable batches
Best for: developers and administrators with shell access who need a repeatable, reviewable change across many posts.
The official wp post list command can preview IDs, dates, titles, and comment status. The official wp post update command supports --comment_status=open|closed for one or more IDs.
Preview first:
wp post list --post_type=post --post_status=publish --fields=ID,post_date,post_title,comment_status --format=tableThen close a known batch:
wp post update 123 456 789 --comment_status=closedFor a whole publication year, wp post list can pass the WordPress year query argument:
wp post update $(wp post list --post_type=post --post_status=publish --year=2024 --format=ids) --comment_status=closedUse batches on very large sites. Giant all-at-once shell commands can hit argument-length limits and are harder to inspect. Years, categories, or known ID groups create safer checkpoints.
Method 4: a Disable Comments plugin for an ongoing policy
Best for: organizations that do not want comments at all, or want a persistent no-comments policy on particular post types or a multisite network.
The official WordPress.org listing for Disable Comments by WPDeveloper can disable comments across posts, pages, media, or the network and remove much of the comments-related admin interface. Its documentation also says not to use it merely for selectively disabling individual posts because WordPress already supports that.
That matches our normal WordPress rule: do not add a permanent dependency to solve a temporary checkbox problem. If “comments are not a feature here” is truly an ongoing policy, a plugin can centralize that decision. Before activation, check whether comments power product reviews, memberships, support threads, or custom workflows.
If you add the plugin, own it like any other production dependency: updates, monitoring, rollback, and compatibility. Our website maintenance guide explains why “installed” is not the same as “owned.”
Method 5: direct SQL for an exact cutoff
Best for: experienced administrators who need an exact date cutoff across a very large site and have a verified database backup plus direct database access.
Direct SQL should change the post’s comment state, not delete the comments. If the goal is to close intake, update comment_status on the matching posts. Do not truncate wp_comments or wp_commentmeta. Those operations destroy data and solve a different problem.
Back up first, then preview. Replace wp_ if your site uses a different table prefix and replace the sample date with the real cutoff:
SELECT ID, post_title, post_date, comment_status
FROM wp_posts
WHERE post_type = 'post'
AND post_status = 'publish'
AND post_date < '2025-01-01 00:00:00'
ORDER BY post_date DESC
LIMIT 50;Only after the preview is correct, run the narrow state change:
UPDATE wp_posts
SET comment_status = 'closed'
WHERE post_type = 'post'
AND post_status = 'publish'
AND post_date < '2025-01-01 00:00:00';If pingbacks and trackbacks also need to close, handle ping_status as a separate explicit decision. A direct database change should be as narrow as the requirement. Because SQL bypasses the normal WordPress application path, verify representative posts immediately afterward and clear the normal persistent cache if the site uses one.
If the database workflow feels opaque, use Method 1, 2, or 3 instead. The database is a lousy place to learn by vibes.
How to verify the shutdown
- Open an old post that should now be closed in a private browser window.
- Confirm the comment form is unavailable.
- Confirm approved historical comments still display when preservation was part of the plan.
- Open a recent post that should remain open and confirm it still accepts comments.
- If you changed pages or custom post types, test at least one representative item from each type.
- If you used SQL or changed a production plugin policy, record what changed, when, and how to reverse it.
This is the same principle behind our Web Development & Technical Optimization framework: a change is not complete when it is typed. It is complete when the intended behavior is proven.
Frequently asked questions
Does disabling comments delete existing comments?
No. Closing comments prevents new submissions; it does not inherently delete approved comments already stored on the post. WordPress’s built-in age setting explicitly leaves previously approved comments visible.
How do I disable comments on all existing posts without a plugin?
Use Posts → All Posts → select the target posts → Bulk actions → Edit → Comments → Do not allow. For large sites with shell access, WP-CLI can set comment_status to closed for controlled batches.
Can I disable comments on pages too?
Yes. Pages also have a comment permission state, and the Pages screen supports bulk editing Comments Allowed. Whether a theme displays a page comment form is a separate presentation question.
Can I reopen comments later?
Yes. Bulk Edit and WP-CLI can set comment status back to open, and the age rule can be disabled or changed. That reversibility is another reason to prefer a state change over deletion.
Close the door; do not burn the guestbook
For most sites, the right way to disable comments on old WordPress posts is a native setting followed by a quick verification. Use Bulk Edit when the set is selective, WP-CLI when the work is large or repeatable, a plugin when the policy is persistent, and SQL only when the scale and precision justify bypassing the normal application path.
If comment cleanup is one symptom of a WordPress site nobody clearly owns—updates are ad hoc, backups are theoretical, and every change feels risky—review what real WordPress maintenance support should include. Good maintenance is intentionally uneventful: scoped, recoverable, tested, and documented.
