A Webflow website review should happen on the published site, where the client can test real content, responsive behavior, and forms. Add Annot8 through Webflow’s site-wide custom code to collect feedback pinned to the page. Keep feedback on the webflow.io staging host separate from the decision to expose the widget on your custom production domain.
Choose the published Webflow URL for the review
Agree whether the review uses your Webflow staging domain or the custom domain. The Designer canvas, a read-only design link, and a published website are different surfaces. This guide concerns the published website. Custom scripts need to run there before a guest reviewer can use the widget; a screenshot of the Designer is not an installation test.
Check that the site’s current Webflow plan and your permissions allow custom code. Webflow’s documentation explains the site-level and page-level fields. Use the site-level field for a review spanning several pages, then publish to the intended host. Keep any existing scripts in place and add the Annot8 snippet once.
Add the feedback widget through site-wide custom code
- In Annot8, create the project and allow the exact Webflow staging hostname used by reviewers.
- Check the project’s environment rules for both the staging host and the custom domain.
- Copy the generated snippet from Project → Settings → Installation.
- In Webflow Site settings → Custom code, add the snippet in the footer code field and save.
- Publish to the selected review host, open that published URL, and submit one test comment from a guest session.
When a production-domain review is intentional, enable Show widget in production in Annot8. Otherwise the script can be present while the panel remains hidden. If the widget appears on webflow.io but not on the custom domain, compare allowed domains, environment matches, and production visibility before changing the snippet.
Review CMS templates with difficult content
Test a CMS item with a long title, another with a missing optional field, and one with the largest realistic image or list. Inspect the same template at narrow and intermediate widths. If only one item breaks, record its URL and content conditions. If every item breaks, identify the shared template so the implementer knows the change has broader scope.
Ask reviewers to exercise interactions instead of commenting only on the first frame. Open the mobile menu, expand accordions, follow pagination, and submit a test form. A screenshot suits a static spacing problem. A short, reporter-initiated recording on a paid Annot8 plan can demonstrate an interaction sequence; it is not passive replay of previous visits.
Page: /case-studies/example Content condition: long client name; optional summary omitted Viewport: 390 × 844 Observation: heading overlaps the image after the menu closes Expected: heading remains readable and the image begins below it Evidence: pinned screenshot plus steps to reproduce Scope: check other items using the case-study template
Retest the published revision before client sign-off
Record whether each comment is a defect, a factual correction, or a proposed new requirement. Get exact copy and a decision owner where needed. After the developer changes the design, republish to the review host and retest there. A saved Designer change is not evidence that the public page has been updated.
Verify form delivery, redirects, and custom-domain behavior during the final acceptance round. Then decide whether the production widget stays visible for ongoing feedback. Give that decision an owner so a staging review setting does not accidentally become a permanent visitor-facing support channel.
