Disable comments field-by-field, not site-wide
Comment fields don't have to match everywhere
Most CMS platforms let you turn comments on or off at the site level. That's too broad. You built a content model with different post types for a reason — use it.
News updates don't need comments. Tutorial posts do. Policy pages never do. Product announcements might, depending on your workflow. Treating all of these the same ignores the structure you already defined.
Set comment availability in the content type definition, not in the global settings panel. Then you control it once per type and apply it consistently without checking boxes on individual posts.
Match comment policy to content function
If a post type exists to deliver information users consume and leave, disable comments in the model. If it exists to gather feedback or build discussion, enable them there.
Don't make this decision based on traffic estimates or how much moderation effort you want to spend. Make it based on what the content type does. A FAQ page that allows comments is a structural contradiction. A how-to guide that doesn't is a missed opportunity.
When you're defining a new content type, add "comments allowed: yes/no" to the same checklist where you decide which fields are searchable and whether excerpts are required.
Override only when the content model is wrong
If you're disabling comments on individual posts inside a type that normally allows them, your content model has a gap. You're using one type to do two different jobs.
Split the type or add a field that marks the distinction. Don't rely on manual overrides every time you publish. That's a production tax you'll pay forever.
The same applies in reverse: if you keep enabling comments on individual posts in a type that has them off by default, you've misclassified the type's function. Fix the model.
Closed comments need a visible state
If comments exist but are closed — either manually or on a schedule — show that state on the page. Don't just hide the comment form. Users who expect discussion will assume the page broke.
A single line of text works: "Comments on this post are closed." If your CMS allows scheduled comment closure based on publish date, show the closure date in the content model and render it in the template. No surprises.
This is template-level work that follows from decisions you made in your content model. The model defines when comments close. The template shows the result.
Test comment permissions separately from publish permissions
Some CMS platforms tie comment moderation permissions to content editing permissions. That's a mistake. The person who writes a post isn't always the person who should moderate its comments.
If your platform conflates these, you'll either over-permission your editors or under-resource your moderation. Check the permission model before you assume comments "just work" after launch.
Comment state belongs in your content model the same way publish date and draft status do. Decide it structurally, enforce it in the type definition, and override only when the model itself needs correction.