Can I check my app before I attach the domain?

Which URL should I grade before launch?

The one strangers can open. On Vercel that is the generated production URL, project-name-scope.vercel.app, or a branch or commit preview URL; on a builder it is the subdomain it gave you. Grade the exact URL that will become the live site, so the bundle, keys and routes are the ones that ship.

Vercel documents the patterns: a commit deployment at project-name-unique-hash-scope-slug.vercel.app, a branch at project-name-git-branch-name-scope-slug.vercel.app, and the production alias at project-name-scope-slug.vercel.app, each publicly accessible by default. v0 deploys to the same place; its documentation says preview deployments have unique URLs and do not change the project's production URL. Lovable, Bolt, Replit and Base44 each give a subdomain of their own, and the grader recognises them all as platform subdomains.

Grade the production alias or the exact branch you are about to merge, not an old commit. The bundle is built per deployment, so a key fixed on Tuesday is still in Monday's preview. The grade's stack line names the host it detected from headers and DNS, which is also the quickest way to find out your custom domain is not actually pointed where you think.

What does a preview grade cover?

Everything that lives in the deployment rather than the domain: TLS and the six security headers, secrets and source maps in the bundle, the database key and whether the REST root lists tables, the Stripe key mode, the 404 status, legal pages, analytics, title, description, Open Graph image, robots, sitemap, cookies, CORS and builder leftovers.

The deployment is where the dangerous classes live, and all of them grade on a preview: secrets-in-bundle, supabase-rest-exposed, source-maps, cors-wildcard-credentials, csp and the other headers, not-found-page, ai-leftovers. Verify ownership of the preview host with the meta tag or the well-known file, since you cannot add a DNS record to a platform subdomain, and the seven verified checks run too: anonymous row reads, open admin routes, env and git files served by URL, listable storage buckets, rate limiting.

Two checks behave differently on a platform subdomain on purpose. stripe-test-key-in-prod warns rather than fails on a pk_test_ key, because a preview is where a test key belongs; it fails only on a production domain. And hsts and the TLS checks grade the platform's certificate and headers, which pass on every major host, so a pass there is the host's work, not yours; the headers that are yours to set are the CSP, frame, referrer and permissions policies.

What has to wait for the real domain?

Anything attached to the domain itself: SPF, DKIM, DMARC, MX and the sending-domain verdict, because a platform subdomain carries no mail; nameservers, DNSSEC and CAA, because the zone belongs to the platform; and domain expiry, because there is no registration. These skip on a preview and run the moment the domain answers.

A skip is not a pass and does not count toward the score, so a preview grade of A means the deployment is clean and says nothing about the domain. The mail checks are the ones that bite on launch day: the sign-in emails only start failing once real users on a real domain try to log in. Add the records before DNS cutover, not after, since DNS is where you are anyway. domain-expiry reads RDAP and needs a registrable name; caa, dnssec and nameservers need a zone you control.

So the sequence is two grades. First the preview, which finds everything in the build. Then the live domain within the hour of cutover, which runs the remaining dozen checks and re-runs the rest against the final URL, where a catch-all rewrite or a redirect loop added for the domain can undo a passing 404 or canonical. The monitor does the second grade on every deploy from then on.

My preview is behind Vercel protection. Can it still be graded?

Yes, with the bypass secret Vercel issues for exactly this. Deployment Protection on Vercel Authentication blocks anonymous requests to previews by default, which blocks every outside scanner. Protection Bypass for Automation is available on all plans and gives a secret the grader sends as a header only to your host.

Vercel's documentation covers both halves. Vercel Authentication is available on all plans and, when enabled, allows only users with deployment access to view the site; standard protection covers every deployment except production domains. Protection Bypass for Automation is available on all plans, generates a secret per project, and lets an automated client authenticate using either an HTTP header or a query parameter named x-vercel-protection-bypass. Password protection, the other method, is on Pro and Enterprise only and is not needed for this.

Create the secret under the project's Deployment Protection settings and give it to the grader with the URL. We send it as the x-vercel-protection-bypass header, and only on requests to that one hostname; it is stored with your verified project and never written into a report. Rotate it from the same settings page when you are done, the way you would any other credential. A protected preview is also a reminder of what protection does not do: it hides the deployment from strangers, and it does nothing about the key in the bundle or the table without RLS that the deployment will carry to the live domain unchanged.

Test it yourself with one request before handing it over:

curl -s -o /dev/null -w '%{http_code}\n' https://PROJECT-git-BRANCH-SCOPE.vercel.app -H "x-vercel-protection-bypass: YOUR_SECRET"   # 200