Disabling comments for new WordPress posts does not necessarily close comments on existing posts or remove comments already published. Determine whether you are seeing a new submission, an old discussion, a pingback or cached output before deleting anything.
Start with one affected URL and its post ID. Note the time you changed settings and the creation time of the comment. A notification arriving late is not proof that a new comment bypassed your latest configuration.
Check the scope of the setting
Review Settings > Discussion, then open the affected post's discussion controls. WordPress's comment documentation separates defaults for new content from controls on individual posts. Inspect the actual existing record rather than assuming it inherited a setting changed later.
If the business wants comments closed on older editorial posts, select the intended set and use supported editing controls. Review the selection before applying a bulk change. Product reviews, membership discussions and custom content types may use different interfaces or business rules.
Separate closing from hiding
Closing comments prevents further submissions through the relevant supported path. It is not a request to delete the historical discussion. A template may continue showing approved comments after the form has disappeared, which can be the intended result.
If the goal is to remove public discussion, decide whether to unpublish, retain privately or delete it under your retention policy. Export valuable moderation history first where appropriate. Do not edit core comment-handling files or run an unreviewed database-wide update.
Late notification: Compare creation time with setting change. Pingback: Review separate notification controls. External widget: Use the provider that owns the discussion. Cached form: Verify stored state before purging the page. Original explanatory guide, not a customer test result.
Identify pingbacks and third-party systems
Check the record type in the moderation screen. Pingbacks and trackbacks are not ordinary typed replies and have separate controls. A third-party commenting widget may store and display discussions outside native WordPress comments.
Inspect which component renders the visible discussion and which route accepts submissions. Removing the widget from a template does not necessarily close its external discussion. Follow that provider's controls and confirm what happens on old URLs as well as newly created posts.
For spam rather than a blanket closure, the WordPress spam guidance describes moderation controls. Use a small review sample so legitimate replies with links are not automatically discarded.
Retest from the visitor's perspective
Open the affected page signed out and in a fresh session. If the form remains visible, compare current origin output with cached output before changing permissions. Clear the relevant page cache only after verifying the stored discussion state.
Use a harmless authorized test on staging to check that a closed post rejects a new comment while an intentionally open control still works. Do not load-test the live endpoint or submit public test spam. Check any mobile template or alternate domain that serves a separate cached copy.
Protected content needs a separate privacy check. Our protected comment and feed guide explains why hiding a page's discussion is not sufficient evidence that every distribution route is private.
Request comment-system troubleshooting when a plugin, external widget and native settings disagree. Supply the affected URL, record type, intended policy and change time. The fix should make each route follow that policy without silently erasing useful customer history.
Sources checked October 1, 2026. Instructions and visuals are explanatory, not claims of customer tests.