A comment form looks like the simplest thing on a site. Name, email, a box for text, a button. That version takes ten minutes to build and produces a specific kind of mess about a month later: a folder of notification emails with no record of which ones were answered, a handful of genuine remarks buried in automated junk, and no way to tell whether the useful comment from three weeks ago was ever replied to.
The template below is short, and most of the work is in the decisions around it rather than the fields themselves. Before any of it matters, one question has to be settled.
Two different things get called a comment form
The first kind publishes. A reader writes something under an article or a product page, it appears on the page for everyone, and the design problem is moderation: holding the first comment from a new person, spotting abuse, and keeping the thread readable.
The second kind routes. Someone leaves a remark about a page, a document, a proposal or a service, it goes to a team, and nobody outside sees it. The design problem here is not moderation but handling: knowing who is dealing with each remark, whether it needs a reply, and whether that reply was sent.
Almost every search for a comment form template is looking for the second kind and finds advice about the first. The two share a text box and nothing else. Public comments belong to the publishing system that renders the page, because that is what can display them. Private remarks belong somewhere that can assign and answer them, which a comment thread cannot do.
Settle this before picking fields. A form that publishes needs a display name and a way to show consent. A form that routes needs a reachable email address and a category, and can leave the display name out entirely.
The template
This is the routing version, which covers suggestion boxes, page feedback, consultation responses, remarks on a draft document, and general "tell us what you think" collection.
Field 1. What is this about? A short list rather than free text. Something like: a page on the site, the product, an order, a document under review, something else. Five options maximum. This single field does more work than the rest of the form, because it decides who reads the remark and how quickly.
Field 2. Which page or item? Optional text, prefilled where possible. If the form is embedded on a page, the page address can be filled in before the respondent sees the form, which removes a question and produces better data than asking people to describe where they were.
Field 3. The remark itself. One open text box, with a label that asks for something specific. "What would you change?" collects more than "Comments", because the second one reads as a formality. Keep the box visibly large. A three line box signals that three lines are expected.
Field 4. Email address. Required if a reply is expected, optional if not, and it should say which. A line reading "only used to reply to this remark" raises completion rates more than any styling change, because the most common reason people abandon a comment form is uncertainty about what happens to the address.
Field 5. Name. Optional, and near the end. A required name field on a form about a page is a barrier with no purpose. On a consultation response it may be necessary, in which case it moves to the top and says why it is needed.
Field 6. Would a reply be welcome? Yes or no. This is the field most templates leave out and the one that saves the most time, because it separates remarks that need an answer from remarks that are simply being recorded. Without it, every comment looks like a question.
That is the whole form. Six fields, two of them optional, one of them a checkbox.
The fields to leave out
Phone number. On a comment form it lowers completion and is almost never used to follow up.
Subject line. The category field in position one already does this, and does it better, because a list can be counted and a subject line cannot.
Company and job title. Worth collecting only if the analysis genuinely splits by them. Otherwise they are two more fields between the remark and the button.
A satisfaction rating. Ratings and open remarks answer different questions and belong in different forms. A rating attached to a comment box gets answered by everyone and analysed by nobody.
A long consent paragraph. One sentence saying what the address is used for, with a link to the full policy, does the job. A wall of text next to the button is where people stop.
Spam, in order of what it costs
Any comment form left open on a public page will receive automated submissions. The defences are worth applying in this order, because the cheap ones catch most of it.
A hidden field. A field that real people never see and never fill in, discarded when it contains anything. Costs nothing, catches the bulk of naive bots, and is invisible to respondents. This is the single highest return measure available.
A minimum time to submit. A form completed in under two seconds was not completed by a person. Discarding those costs nothing and affects nobody.
Requiring a working email address. Not validation of the format, which bots pass easily, but sending the reply or confirmation to the address and treating a bounce as a signal. This has the useful side effect of confirming the address before anyone tries to reply to it.
A challenge such as a picture puzzle. Effective and not free. It slows every genuine respondent down and causes real accessibility problems, so it belongs on forms that are already under sustained attack rather than on every form by default.
A spam filtering service. Akismet is the common choice for comment traffic. Its pricing is metered by spam checks rather than by site traffic, with the lowest commercial tier covering 500 checks a month for one site and the business tier covering 5,000 across unlimited sites, plus a pay what you can option for personal sites. Useful for high volume public comment threads, and usually unnecessary for a routing form that receives a few dozen remarks a week.
Form tools differ in how much of this is built in. Tally includes duplicate submission prevention, password protected forms and the ability to close a form on a date or a submission limit on its free tier. Typeform lists a challenge field among its features. Contact Form 7, the free and open source WordPress plugin, leaves spam handling to add-ons you choose yourself. Checking which layers a tool provides before building is faster than discovering the gap in production.
Where the form goes, and what the button says
Placement beats wording. A comment form at the bottom of a long page collects from the small number of readers who reach the bottom. A persistent link in the page furniture, opening the form without leaving the page, collects from everyone. For remarks on a specific document or proposal, a link next to each section collects better than one link at the end, because the remark arrives attached to the thing it is about.
Button wording is worth thirty seconds of thought. "Submit" is the default and the weakest option, because it describes what the software does rather than what the person is doing. "Send remark" or "Send it" perform better. Any wording that implies a commitment, such as "Sign and send", performs worse.
One more thing belongs on the page rather than in the form: what happens next. A line saying a reply usually comes within two working days, or saying plainly that remarks are read but not individually answered, sets an expectation and prevents the follow up messages that arrive when people assume their comment went nowhere. Saying nothing is the option that generates the most extra work.
After the remark arrives
This is where the ten minute version of a comment form falls over. Notification emails have no shared record, so with two readers either both reply or neither does, and there is no way to see a week later which remarks were handled.
Every arriving remark belongs in one of three buckets, and the sorting takes seconds if the form asked the right questions. Needs a reply, which the yes or no field already told you. Needs recording, meaning a genuine point that requires no answer but should be counted. Needs nothing, meaning spam and duplicates. The first bucket needs an owner and a status. The second needs to be countable at the end of the quarter. The third needs to be removable without reading.
| Where comments live | Good for | Moderation | Assigning a reply |
|---|---|---|---|
| Comment thread in a publishing system | Public discussion under content | Built in, since publishing is the point | Not supported, there is no owner field |
| Form plugin sending notification email | One person handling a low volume | Whatever the mail client offers | Manual, by forwarding and hoping |
| Spreadsheet fed by a form | Counting and reporting | Add a column and maintain it by hand | Possible, breaks with two editors |
| Form tool with response management | Recurring collection read by a team | Filters and bulk actions on the list | Owner and status on each response |
The second bucket, the remarks that need recording rather than answering, is the one worth protecting. It is where the value of a comment form accumulates. Forty remarks over a quarter, each individually minor, become an argument for changing something once they can be grouped and counted. That only happens if the category field was a list rather than free text, and if nothing was deleted along the way to keep the view tidy.
The last row is the one that matters once more than one person reads the form. A tool that keeps an owner, a status and the reply history on the response itself removes the question of who was dealing with what, and the situations where that pays off are the repetitive ones: page feedback that arrives every week, a consultation that runs for a month, a suggestion box that is supposed to outlive the person who set it up.
Volume matters for the choice of tool rather than for the design of the form. Comment forms are unpredictable by nature, quiet for weeks and then busy after something is published, which fits badly with pricing metered by monthly responses and fits well with pricing based on the number of people reading.
What to change first
Add the two fields most templates omit, which are the category at the top and the "would a reply be welcome" checkbox at the bottom, and put a hidden field in before the form goes live. Then decide where remarks land and who owns a reply, because that decision, and not the field list, is what determines whether anything gets answered in week four. Halict shows what the second half looks like on a single remark.
Q1. What fields should a comment form have?
A category list, the remark itself, an email address, and a checkbox asking whether a reply is welcome. Name and page reference are useful as optional fields. Phone number, subject line and job title can go, since they lower completion without changing what anyone does with the remark.
Q2. Should a comment form require a name and email address?
An email address should be required only if a reply is expected, and the form should say what the address is used for. A name is rarely worth requiring on a comment form about a page, because it adds a barrier without changing how the remark is handled. Consultation responses are the exception, and there the reason for asking belongs on the form.
Q3. How do you stop spam on a comment form?
Start with a hidden field that only bots fill in and a minimum time to submit, since both cost nothing and catch most automated traffic. Confirming the email address by sending to it catches more. Picture puzzles and paid filtering services are worth adding only once a form is under sustained attack, because they slow down genuine respondents too.
Q4. Is a comment form the same as a contact form?
They overlap and the expected outcome differs. A contact form implies a reply, so it needs a reachable address and an owner. A comment form may be collecting remarks that are counted rather than answered, which is why a field asking whether a reply is welcome is worth including rather than assuming one way or the other.
Q5. Where should a comment form be placed on a page?
A persistent link in the page furniture collects from more readers than a form at the foot of a long page, since only a fraction of readers reach the bottom. For remarks on a document or proposal, a link beside each section works better than a single link at the end, because the remark arrives already attached to the part it refers to.