A documentation site earns one narrow question, not a survey.

What a docs site actually needs

Documentation feedback is not a satisfaction survey. The reader has one of three states: the page solved it, the page was close but missing something, or the page was the wrong page. A single question can separate those; a rating scale cannot, and a five-field form will not be filled in by someone who is still mid-task.

<form action="https://freelyform.com/f/FORM_ID" method="POST">
  <input type="hidden" name="_subject" value="Docs feedback">
  <input type="hidden" name="page" value="/reference/webhooks/retries">

  <label for="feedback">Did this page answer your question? What was missing?</label>
  <textarea id="feedback" name="feedback" rows="3" required></textarea>

  <button type="submit">Send</button>
</form>

Why the page path is not optional

Feedback without a page is a complaint you cannot act on. On a documentation site the path is the single most valuable field, and it is the one you never have to ask for — send it as a hidden value, or encode it in the link so a linked form page arrives pre-filled.

Hosted builder reality

GitBook is designed around documentation blocks: paragraphs, code, callouts, tabs, API references. A general form is not its centre of gravity, and available blocks differ between plans and versions. That leaves three honest routes — an embed, a custom block, or a link out to a hosted form page — and all three keep the record outside the docs tool, which is the outcome that matters.

Close the loop where readers can see it

When three readers say a page is missing the same step, add the step and say so in a changelog entry. Documentation feedback that visibly changes the page gets more of it; feedback that vanishes into a folder stops arriving, and you will read the silence as satisfaction.