How to Ask for Feedback on Your Website Without Annoying Your Visitors

Most website surveys get the same treatment as cookie banners: closed before anyone reads them. That isn’t because visitors don’t have opinions. It’s because the question arrives at the wrong moment, to the wrong person, for the third time this week.

Get those three things right and a website survey becomes one of the best feedback sources you have. The person is on your site, the experience is a few seconds old, and one tap is all it takes to answer.

Here’s how to do it well, whatever tool you use.

1. Ask about something that just happened

The best on-site question is about the thing the visitor has just done. Memory is fresh, and the question makes obvious sense.

• After a checkout or signup: “How easy was that?” (a CES question) or a one-question CSAT.
• On a help article: “Did this answer your question?” with a yes or no, and a comment box for the no.
• After someone uses a feature for the first time: “How useful was this?”
• On your pricing page: “Is anything here unclear?”

Compare that with an NPS question that pops up three seconds into someone’s first visit. They haven’t experienced anything yet, so the answer means very little.

So the trigger matters more than the design. “On page load” is the default in most tools, and the weakest. Prefer a trigger tied to an action: an event your site reports (a finished checkout), a click on a specific button, scrolling most of the way down an article, or a set time actually spent reading the page.

2. Choose who gets asked

Not every visitor should see every question. A few rules cover most cases:

• First-time visitors shouldn’t get loyalty questions. Ask returning visitors how likely they are to recommend you, and ask new ones whether they found what they came for.
• Signed-in customers can be asked about your product. Anonymous visitors usually can’t tell you much about it.
• Plan or role matters for product questions. An admin and a viewer use your product differently, and so do a trial and a paying account.
• Where the visit came from is useful too. Visitors from a campaign can tell you whether the landing page matched the ad. Visitors from search can tell you whether the page answered their search.

Targeting this way does more than avoid annoying people. It keeps your results clean. An NPS average that mixes first-time visitors with three-year customers tells you nothing about either group.

3. Ask fewer people, less often

Two settings do most of the work here.

Sampling. You rarely need every visitor’s answer. Showing a question to 10 or 20% of visitors gets you plenty of responses on a busy page and spares everyone else. It works best when each visitor is placed once, so the same person isn’t in the sample one day and out of it the next.

Frequency. Decide what happens after someone answers, and separately what happens after someone closes the question without answering. “Never ask again” is right for a one-off question. For a recurring pulse, wait months, not days. Closing without answering is an answer too: wait a good while before trying again.

If you run more than one survey on the same site, add a quiet period across all of them. Five well-targeted surveys can still hit one visitor five times in a week. A rule like “after any survey shows, the others wait 14 days” stops that.

4. Keep it to one or two questions

A website survey isn’t the place for a twelve-question survey. Ask the one question you need, and at most one follow-up, usually a comment box: “What’s the main reason for your score?”

Make sure you keep a half-finished answer. Plenty of people will tap a score and then close the card or leave the page. That score is still a real answer, and you want it in your results.

5. Send each answer to the person who can act on it

A website survey creates a steady trickle of answers, not a batch. A dashboard you check once a month misses most of their value. Route answers as they arrive instead:

• A low rating on a help article becomes a ticket for the support team, with the page it came from.
• A detractor score from a signed-in customer becomes a task for their account manager.
• Every comment from the pricing page goes to a Slack channel the marketing team reads.

To do this, each answer needs to carry the page it came from, and the person who gave it when they’re signed in. Check that your tool records both, and that you can turn the page off if the paths themselves are sensitive.

6. Be clear about consent and what you store

Any website survey tool stores something in the visitor’s browser, at least enough to remember that it already asked. In many countries, storing that needs the visitor’s consent first. Your cookie banner should list it, and your tool should be able to wait until the visitor has said yes.

Targeting on past behaviour means the browser keeps a little more: counts of what the visitor did and where their visit came from. Two habits keep that safe:

• Know exactly what your tool stores, and whether any of it leaves the browser.
• Don’t put personal details such as email addresses in campaign tags (utm_source, utm_campaign) on links. Tools that read those tags store them as they appear.

Doing this in SurveyRock

SurveyRock’s website widget shows one of your surveys on your site or in your product, as a small card in a corner or a tab on the edge of the page. You paste one snippet for the whole site, then set up each survey’s widget on its Distribute page. It’s on the Team plan and up.

What the steps above look like there:

• Triggers: on page load, after time on the page (counted only while the page is in view), after scrolling a share of the page, when the visitor is about to leave (desktop), when your site reports an event with SurveyRock('track', 'checkout_completed'), when someone clicks an element you name with a CSS selector, or only when your code calls SurveyRock('show').
• Who sees it: page rules, device type, signed-in or not, and a share of visitors. Each browser is placed once, so the same person keeps the same answer. On the Growth plan and up you can also target by visitor details (traits your site passes about a signed-in visitor, such as plan or role) and visitor history: events they’ve done before, page views, first or returning visits, and the referring site or UTM values of the visit.
• How often: separate rules for after an answer and after a close, plus a quiet period across every widget on the site.
• Half-finished answers count. By default, a visitor who answers and then closes the card (and usually one who leaves the page) has a finished response, marked as closed early. Your workflows run on it.
• Workflows: answers carry the widget’s name, the page’s path (unless you turn that off) and the event that opened it. Response Submitted workflows can post them to Slack, and on the Pro plan and up open a Zendesk ticket or create a HubSpot task. On Growth and up, a visitor your site identifies with a signed identity is linked to their contact, which is what lets a HubSpot task land on the right person.
• Consent: the widget keeps one item in the visitor’s local storage, never sent to SurveyRock, and can wait to store it until your site calls SurveyRock('consent', true). The survey inside the card keeps its own cookies, partitioned to your site, so a visitor can come back to a half-finished answer. Our Cookie Policy describes both for your visitors.

Every setting is in the guide to when the widget shows, and how often, and the banner side is in the website widget and cookie consent.

Next step: Add the website widget to your site. You need a survey to show and one snippet on your site.