Guest Post Submission Form Fields: What to Ask

A contributor form decides who reaches your editors before any editor has read a word. If it asks too little, the inbox fills with pitches you cannot sort. If it asks too much, serious writers give up halfway. The aim is a form where each question earns its place by changing a decision you will actually make.

Short answer: Ask for identity, topic, reader benefit, a link request, any payment or exchange, and how automation was used. Keep required fields few, make two or three screening questions depend on knowing your site, and explain why the sensitive questions are asked. If you publish outside contributors, run a garden blog, a trade magazine or a company knowledge base, you can trim or extend the field list below to fit.

A form is a filter, not an inbox

Every question has two effects. It collects a fact, and it shapes who answers. A question that needs a paragraph about your own site slows down a sender who mails the same pitch to fifty publishers, while it barely slows a writer who has read your archive. That asymmetry is the whole point of screening questions: they cost genuine contributors a minute and automated senders real effort.

Google's helpful content page gives you a vocabulary for why these fields exist. It asks whether it is self-evident to visitors who authored the content, whether pages have a byline where one might be expected, and whether the use of automation, including AI-generation, is self-evident to visitors through disclosures or in other ways. It also says that content should be created primarily to help people rather than to attract search engine visits. The form is where those questions first meet a real submission. Source: Google Search Central: Creating helpful, reliable, people-first content (Opens in a new tab).

A written guest post policy page and the form should say the same things. The policy tells writers what you expect before they type, and the form collects exactly the information that lets you check those expectations.

What a form cannot do

• It cannot verify anything. Answers are claims, and checking them is the editor's job.
• It cannot replace reading the draft. A well-filled form can still precede a weak article.
• It cannot be your only defence against mass submissions. It raises their cost; it does not stop them.
• It should not collect personal data you will never use.

Field by field: what each question buys you

Group the fields by purpose: who is writing, what are they proposing and what are they declaring. The order matters too. Start with the easy identity fields, move to the proposal, and put declarations last, when the writer is already invested.

Identity fields

Name, email and a public profile are the minimum. The profile URL is the strongest of the three because it gives you something outside the form to compare against. How you do that comparison is a separate verification task; the form only needs to capture the address. Practical suggestion: keep name, job title and organization in separate fields, so the author box on the live page can be built cleanly.

Proposal fields

Ask for a one-sentence topic, a short note on who the piece helps and, optionally, a three-bullet outline. The outline shows whether the writer has actually planned the piece. Skip a required headline field: an editor will likely rewrite the headline anyway, so asking for one only adds friction.

Declaration fields

Declarations cover the link request, any payment or exchange, prior publication and automation. Put a short because-line under each one, such as "We ask about payment so we can label links correctly." That sentence turns a question that can feel like an accusation into a routine step of your publishing rules.

Screening questions that resist templates

A screening question works when a pasted answer would read wrong. These five can be adapted to your site:

1. Which reader question on our site does this piece answer that our archive does not?
2. What first-hand example or detail from your own work will the piece use?
3. Has any version of this piece been published or offered elsewhere?
4. Will any tool, including AI, be used to draft or edit the text, and how?
5. Which page do you want to link to, if any, and what does a reader gain from it?

The first and fifth questions do the heavier screening. A writer who knows your site answers the first in a sentence. A sender who does not, writes something that could describe any site, and that difference is visible in seconds.

Reading the answers

Length is not the measure. A two-line answer that shows knowledge of your site beats a long one that could belong anywhere. Identical sentences across different pitches suggest a shared template; the form's job is to make that visible, and what you do about it belongs to the draft review.

The money and link questions

These two questions deserve their own section because they decide how the finished page is labelled. Google's guidance on qualifying outbound links separates three values. It says to mark links that are advertisements or paid placements with sponsored, notes that nofollow was previously recommended for them and remains acceptable though sponsored is preferred, recommends marking user-generated content links such as comments and forum posts with ugc, and says to use nofollow when other values do not apply. It also says you may specify multiple rel values as a space or comma-separated list. Source: Google Search Central: Qualify your outbound links to Google (Opens in a new tab).

The guidance does not address guest posts as such, so the mapping to your form is your own policy choice. A workable mapping:

Decision question: should the form ask whether money changed hands?

Yes. Offer three answers: no payment, payment or exchange, and prefer not to say. The third is useful data too, because it tells the editor to treat the pitch cautiously. The question does not verify anything; it makes the issue visible early, when changing the plan costs nothing. Without it you can learn about payment on publication day, which is the worst moment to change a label or a disclosure.

Auto-reply and the response-time promise

The auto-reply confirms receipt, repeats what was recorded, links to the policy and states a target response time. Choose the word target on purpose. A target you sometimes miss is honest; a guarantee you sometimes break erodes trust. Size the target to real capacity, since a one-person blog and a six-editor desk cannot promise the same thing.

What the auto-reply must not contain

• Any hint of acceptance. An auto-reply is not a decision.
• Promises about links or search results. No placement can guarantee a ranking.
• A full copy of the personal data entered. A topic and link summary is enough.

Pre-launch checklist

• Every field maps to a decision you will make.
• Required fields number six or fewer.
• At least two screening questions need site-specific answers.
• The payment and link question has three answers and a one-line reason.
• Automation use is asked about, and you know what you will do with the answer.
• The auto-reply links the policy and says target, not guarantee.
• Form and policy page state the same rules.
• Personal data collected has a stated purpose and a retention period.

Example: a gardening site takes its first outside pitches

Example scenario: A gardening site run by two people opens contributions. The form has six required fields and five screening questions. A pitch arrives from a landscape designer proposing a piece on drought-tolerant borders, with a bio link to her studio.

The designer answers the reader-question prompt by pointing to a gap between two existing posts on mulching and plant selection. She names a first-hand project as her example, says no payment is involved and states that she will draft the text herself and use a spell checker. The outline has three clear bullets. The intake owner moves the pitch to draft and notes the bio link for the publication checklist.

Another pitch on the same day leaves the site-specific question with a generic sentence, gives a profile URL that does not load and selects prefer-not-to-say on payment. The intake owner rejects it with an identity-not-verified code. The form did not decide either case, but it made the difference visible in a minute.

Privacy and retention

A contributor form collects personal data: a name, an email address and a profile URL. Use it only to assess the pitch and keep the record. Practical suggestion: add one paragraph under the form saying why the data is collected, how long rejected pitches are kept and who can see them. Keep the shared tracking table restricted, and remove access when a team member leaves.

Testing the form before launch

Run four tests: a real writer candidate, a teammate, someone who has never seen the form and someone who behaves like a bulk sender. Time the real candidate and note where they hesitate. Check that the teammate can read the stored record. Ask the newcomer what each label means. Have the bulk-sender persona try short generic answers and see which question stops them.

Accessibility basics

• Every field has a visible label; placeholder text is not the label.
• Error messages name the field and the fix, such as "The profile address must start with http or https".
• The form works with a keyboard alone and the focus order makes sense.
• Required fields are marked in text as well as colour.
• A support email exists for writers who cannot use the form.

Deciding what to keep: a three-question rule

Run every field through three questions. If the answer to all three is no, remove the field.

1. Does the answer change an accept, reject or label decision?
2. Would it be cheaper to ask the writer during editor review than on the form?
3. Do you want to reject writers who leave it blank, or only note it?

A yes to the first keeps the field. A yes to the second makes it optional. For the third, choosing to reject makes the field required, and choosing to note makes it optional. Applied once a year, this rule stops the form from swelling with questions added after one-off incidents.

Field order and the writer's experience

People answer more carefully when the form feels like a conversation. Begin with the small, factual fields, move into the proposal where the writer has something to say, and finish with declarations. Give each section a plain heading, and show a progress cue if the form spans several screens. Mobile matters: some writers will submit from a phone, and long dropdowns or tiny fields raise the chance of abandonment.

Error messages that help

An error message should name the field and the fix. "Invalid input" tells the writer nothing; "The sample URL must start with http or https" lets them correct it in seconds. Keep entered values after an error so nobody retypes a paragraph.

Confirmation on screen and by email

After submission, show a confirmation on the page and send the auto-reply. Two signals reduce duplicate submissions from writers who are unsure whether the first one went through. Duplicates are a real cost: they split the record and invite two different replies to one person.

Managing form versions

A form changes over time, and each pitch should be traceable to the version that collected it. A simple change log works: date, what changed and why. If you use a hidden version field, validate it on the server and remember that a sender can alter it; it exists for record keeping, not for decisions.

The log pays off a year later when someone asks why a question exists, and when you read rejection statistics and need to know which form period they came from.

Where the form stops and the next step starts

The form hands a structured record to the review process. From that point an editor reads the draft, someone verifies the author and a publishing owner checks labels and links. If the form tries to do these jobs, it becomes long and still fails at them; if it does its own job well, the later steps start from good information. Think of it as the first of several checks, tuned to make later checks cheaper.

It also protects you in a modest way. When a writer states in a recorded field that no payment was involved and the facts turn out otherwise, your decision trail is clear. That is good record keeping.

Edge cases the form should anticipate

• Agency submissions: a pitch sent on behalf of a client needs both the sender and the named author. Add an optional field for the person who will be credited, and ask who owns the draft.
• Team authors: when several people wrote a piece, ask for each name separately, because the byline should list every author presented on the page.
• Returning contributors: offer a shorter route for authors you have already published, but keep the payment and link questions, since those answers can change with each pitch.
• Non-native writers: allow a pitch in a second language only if your editors can read it, and say so on the form.
• Corporate authors: ask for the organization's public page and the credited person's role.

Each exception costs one field or one sentence. If an exception needs a whole new form, handle it by email instead and keep the main form simple.

Keeping the form current

Review the form when one rejection code keeps recurring, when editors ask writers for the same missing detail by email, or when a field is barely read. Record each change with a date so you can later tell which version of the form a pitch arrived through.

Reply templates to keep beside the form

Three short templates save time: a request for missing details, an off-topic rejection and a note about a missing disclosure. Each states what is missing, why it matters, a target date and what happens if no reply arrives. The wording of the replies themselves is covered in replying to guest post and link offers. Personalise each with the writer's name and one detail from the pitch before sending; a template sent unchanged makes you the sender you are trying to screen out.

Three signals that the form is working

Judge the form from the archive, not from a hunch. Practical suggestion: once a month, look at three measures.

• Required fields filled with empty or meaningless text: if the same field is skipped repeatedly, its label or hint is unclear.
• Whether screening answers are specific to your site: if you see the same sentence across several pitches, a template can answer the question.
• Days from submission to decision: how many pitches ran past the time you promised in the auto-reply.

When one gets worse, change the label or question first, leave the form untouched for two weeks, and look again. Changing several fields together hides which change helped.

A small fix, as an example

Suppose a pitch field called "Topic idea" keeps receiving one-word answers. Renaming it to "Working title, plus one existing post on our site you would link to" splits the question into two clear parts. Record the date of the change in the form version note.

Frequently Asked Questions

How many required fields should a guest post form have?

There is no fixed number. Practical suggestion: six required fields cover name, contact, public profile, topic, reader benefit and a sample. Each required field should map to a decision.

Should the form ask whether payment was involved?

Yes, with three answers: no payment, payment or exchange, and prefer not to say. Google's guidance says paid placements are marked with sponsored and that nofollow is still acceptable, so the answer feeds the label decision before the draft is written.

Is it worth asking about AI use?

Google's helpful content page asks whether the use of automation, including AI-generation, is self-evident to visitors. Asking up front lets you decide how to handle it before the draft arrives.

Will a form stop mass submissions?

No. Site-specific questions raise the effort for bulk senders, but the form cannot prove anything. Identity and draft checks continue after the form.

What should the auto-reply promise?

A target response time, not a guarantee, and nothing about acceptance, links or search results.

Should I ask for ID documents?

Not on the form. A public profile is a sufficient starting point, and you should collect only the personal data you need.

Conclusion

A good contributor form asks questions that change decisions. Identity fields let you compare a claim with something outside the form, proposal fields test topic fit and reader focus, declaration fields connect money, links and automation to the label you will apply, and the auto-reply sets honest expectations. The form raises the cost of careless submissions without verifying anyone, so identity checks and draft review stay downstream.

If you would rather start from a placement service that records publication details, see our guest post service.