StoreProof — Automated Shopify Storefront QA

Shopify storefront issues can exist without producing an obvious visual failure.

A product page may load normally while Add to Cart fails. A critical action may work on desktop but become difficult to use on mobile. JavaScript errors, failed network requests, accessibility problems and missing metadata can remain unnoticed until customers encounter them.

For commerce teams, these issues are directly tied to the buying experience and can create unnecessary friction or lost revenue.

The challenge was to build a tool that could inspect a public Shopify storefront from the customer side, identify meaningful problems and explain the findings without requiring access to the merchant’s Shopify Admin.

StoreProof was designed as a standalone Shopify storefront QA platform.

A user submits a public store URL and StoreProof opens the storefront in a real Chromium browser, follows the customer experience and produces a prioritized audit report.

The scan does not require:

Shopify Admin access A Shopify app installation Customer account credentials Checkout access

StoreProof performs safe storefront interactions but deliberately stops before checkout, payment or order creation.

This keeps the initial audit frictionless while still allowing the platform to test the parts of the storefront that directly affect a customer’s ability to browse and purchase.

StoreProof does not evaluate a storefront as a collection of isolated pages.

The scanner attempts to follow an actual commerce journey:

Homepage → product discovery → product page → variant state → Add to Cart → cart verification → mobile validation

Products are discovered directly from the storefront and a controlled sample is selected for testing.

Playwright controls a real Chromium browser so the scanner can observe rendered pages, interactions, JavaScript behavior and network activity rather than relying only on static HTTP responses.

Commerce interactions are intentionally limited to avoid aggressive crawling or unnecessary cart mutations.

StoreProof evaluates six major areas of storefront quality.

Commerce — 30% Product interaction, Add to Cart behavior and the buying journey.

Mobile — 20% Critical storefront interactions and usability at mobile viewport sizes.

Performance — 15% Performance-related storefront conditions and page behavior.

Accessibility — 15% Automated accessibility analysis using axe-core together with browser observations.

Technical — 10% JavaScript errors, failed resources, network behavior and technical storefront issues.

SEO — 10% Titles, descriptions, canonical information and other storefront SEO signals.

Commerce and Mobile receive the greatest weighting because failures in these areas are closest to the customer’s ability to complete a purchase.

The most difficult part of StoreProof was not finding errors. It was deciding when the scanner had enough evidence to fairly classify something as broken.

Every important check can end as:

Passed Failed Inconclusive Not tested Excluded

Only confirmed findings with sufficient evidence should reduce storefront health.

If StoreProof cannot verify an interaction because automation is blocked, authentication is required or the response is ambiguous, the check can remain inconclusive instead of becoming a merchant failure.

This prevents limitations of the scanner from being incorrectly presented as problems with the business being audited.

StoreProof intentionally avoids presenting one number as the complete truth.

Each report separates three different concepts.

Store Health Score

Represents the health of the storefront based on findings StoreProof was able to confirm.

Audit Coverage

Represents how much of the intended storefront journey and audit surface was successfully tested.

Result Confidence

Represents how strongly the available evidence supports the result.

A storefront can therefore receive a strong health score while still showing reduced coverage or confidence when important parts of the journey could not be verified.

When the evidence is incomplete, the report can be marked provisional.

This makes uncertainty visible instead of hiding it behind a confident-looking score.

Real production storefronts do not always respond to browser automation the same way they respond to a normal shopper.

StoreProof therefore interprets network responses conservatively.

HTTP 401, 403 and 429 responses are treated as scanner or automation limitations rather than immediate proof of a broken storefront.

Ambiguous cart responses such as 400, 409 and 422 are not automatically converted into confirmed commerce failures without stronger evidence.

A confirmed product 404 can provide much stronger evidence that a discovered storefront URL is genuinely broken.

If rate limiting is detected, the scanner activates a circuit breaker and stops unnecessary commerce mutations instead of repeatedly requesting the same store.

This classification layer became critical to producing reports that are useful without unfairly blaming the merchant.

StoreProof uses a distributed architecture because real-browser scans are significantly heavier and longer-running than normal web requests.

Next.js 16 + React 19 + TypeScript Public application, report interface, API routes and scan submission.

Vercel Hosts the public StoreProof application.

PostgreSQL + Neon Stores scans, findings and report data.

Redis + BullMQ + Upstash Queues scans and separates browser workloads from incoming web requests.

Node.js 22 + Playwright + Chromium Runs the storefront scanning engine.

Railway Hosts the long-running Playwright worker independently from the Vercel application.

Supabase Storage Stores screenshots and scan artifacts using S3-compatible object storage.

This architecture allows the public application to accept a scan quickly while the browser worker processes the storefront independently.

A StoreProof scan moves through several independent services.

The customer submits a Shopify storefront URL through the Next.js application.

The application validates the URL and creates a scan record.

The scan job is sent to Redis and BullMQ.

A Railway worker receives the job and launches Playwright with Chromium.

The worker navigates the storefront, performs the audit journey, captures findings and records evidence.

Structured results are written to PostgreSQL while screenshots and artifacts are stored separately in object storage.

The public application then reads the completed scan data and renders the final StoreProof report.

This separation keeps the customer-facing application responsive while allowing browser automation to run as a controlled background workload.