Guest Feedback Links: Collecting Bug Reports Without an Account

The client feedback problem

You're doing a pre-launch review with a client. They find three bugs. They describe them via email with no screenshot, no browser info, and no context. You email back asking for details. They send a blurry phone photo of their monitor.

Or: you're coordinating a QA round. Your QA contractor doesn't have a GitHub account. They send bug descriptions in Slack. You manually create GitHub issues. Half the context is lost in translation.

The best bug report is the one that gets filed. If the process is too hard, bugs go unreported or arrive with no useful information.

What guest links are

A guest link is a URL that opens a browser-based bug report form — no extension, no account, no install required. The person reporting clicks the link, describes the issue, and submits. The report lands in your Site Reviewer dashboard with their browser, OS, URL, and any screenshots they attach.

From the reporter's perspective, it's just a form. From your perspective, it's a structured report with all the metadata.

Creating a guest link

In the Site Reviewer dashboard, go to Guest Links and click "New link." You can configure:

• Label — who or what this link is for (e.g., "Client UAT - Acme Corp")
• Project — which project reports should be filed under
• Expiry date — the link stops accepting submissions after this date
• Use limit — maximum number of submissions

Copy the generated URL and send it to whoever needs to report bugs. You can revoke it at any time.

What guest reporters see

A simple form with:

• Title field
• Description field
• Type selector (Bug, Visual, Content, Suggestion, Other)
• Severity selector
• Optional screenshot upload

Their browser, OS, screen resolution, and the URL they're on are captured automatically from the form itself.

Recommended use cases

Client UAT (User Acceptance Testing)

Create a link per client engagement, set an expiry date aligned with the UAT window, and share it with the client. All their reports land organized by project. When UAT ends, the link expires — no cleanup required.

Beta testing

Share a single link with your beta user group. Set a use limit to gate the number of reports if you want to control volume. Review and triage in the dashboard.

External QA contractors

Create a link per QA contractor (or per QA round). Reports are labeled with the link name, so you know who filed what. Revoke the link when the engagement ends.

Website contact pages

Embed a guest link on an internal staging or review URL. Anyone who visits the staging site can report issues directly — no coordination required.

Security and access control

Guest links are tokens — knowing the URL is the only credential required. Treat them like API keys: share them only with the intended recipients, set appropriate expiry dates, and revoke them if they're accidentally shared too broadly.

Guest reporters cannot see other reports. They can only submit. All review and management happens in the Site Reviewer dashboard, which requires your API key to access.

vs. just asking clients to email

Email bug reports arrive in free text, with no consistent format, no automatic metadata, and no integration with your issue tracker. Every email report requires manual triage: reading the email, extracting the details, creating the issue, tagging it, and filing it.

A guest link report arrives pre-structured with title, description, type, severity, browser, OS, and URL — ready to route to GitHub, Linear, GitLab, or Azure DevOps with one click.