Key Points for AI-Powered Browser Checks After a Shopify Theme Change
After making changes to a Shopify theme, you can hand off the "is anything broken?" check to AI. Major AI tools like Claude and Codex can operate the browser directly through a Chrome extension, so you can have them do the actual work of opening a page, scrolling, clicking, and verifying.
In this article, we'll look at how this can be used for browser testing on a Shopify store, along with prompt examples that actually work.
What it means for AI to operate Chrome
Claude (the Claude in Chrome extension) and Codex (Chrome extension) can operate the browser through a Chrome extension. When used for store testing, the AI does the following:
- Actually opens a page and "sees" the rendered screen
- Scrolls to check elements that are off-screen
- Performs actions such as clicking, typing, and resizing the window
- Puts anything it notices into words and reports back
Because it runs through a Chrome extension, it uses the session and cookies of the Chrome you normally use. That means it can access a logged-in store preview as-is.
The big difference from conventional automated testing is that it can evaluate the state as it actually appears on screen, not just confirm that elements exist in the DOM.
Prompt examples you can use
Purchase flow check
This is the basic test to run first after a theme change.
Please check the purchase flow of the Shopify store (https://xxx.myshopify.com). Actually perform the following steps in order, and point out anything you notice at each step: 1. Open the homepage and check that there are no issues with the layout, header, or footer 2. Check the product listing on the collection page (image loading, price display, grid breakage) 3. Open a product detail page (images, variant selection, visibility of the add-to-cart button) 4. Add to cart and check the cart page (product info, quantity, total amount display) 5. Proceed to checkout (do not perform any actions beyond this point; just check the state of the screen) Pay particular attention to the following: - Whether buttons and links look visually clickable (color, size, overlap) - Whether text is a readable color and size - Whether images load correctly - Whether the layout breaks at mobile width (390px) * No action is needed on the checkout page. Display check only.
Post-change diff check
This is useful after adding a specific block or feature. You can confirm "whether what you added is displayed" and "whether it interferes with the existing layout."
I made changes to the theme, so please check whether any issues have appeared on the following page. Change made: Added a collection link block to the product page. Page to check: https://xxx.myshopify.com/products/sample-product Check points: 1. Whether the added collection link is displayed 2. Whether the label "Collections containing this product" and the link button appear correctly 3. Whether it interferes with the existing layout (product image, title, price, add-to-cart button) 4. Whether it breaks at mobile width (390px) 5. Whether clicking the collection link navigates to the correct page
Responsive check
This is useful for checking the display at both desktop and mobile widths.
Please check the following page at both desktop and mobile widths and report any layout breakage. URL: https://xxx.myshopify.com/collections/all Check procedure: 1. Check the whole page at a window width of 1280px 2. Change to a window width of 390px (iPhone equivalent) and check again 3. Check the following at both widths: - Whether navigation works (including the hamburger menu behavior) - Whether the product grid is laid out correctly - Whether text overflows - Whether product images display at the correct aspect ratio - Whether the filter and sort UI is in an operable state
Form interaction check
This is useful for checking screens that involve forms, such as a contact page.
Please check the contact form page (https://xxx.myshopify.com/pages/contact). 1. Whether the form is displayed correctly visually 2. Whether required fields are clearly distinguished 3. Actually enter values in each field and check the UI changes on focus (border color change, etc.) 4. Press the submit button while leaving fields blank, and check whether validation errors display correctly 5. Whether error messages appear in a prominent location * Do not actually submit. Stop at the validation check.
Navigation and broken link check
This is useful after changing the menu structure or adding a new page.
Please check all of the site's navigation. Target: the header menu of https://xxx.myshopify.com What to check: 1. Click each header menu item and check whether it navigates to the correct page 2. If there are dropdowns, check all of the items inside them too 3. At mobile width (390px), open the hamburger menu and check the same way 4. Report any links that result in a 404 Please check the footer links in the same way.
Generating a test report
Once a series of checks is finished, you can have it generate a report at the end. Because you're left with an organized record of what was checked, the issues found, and the recommended actions, it's useful for sharing with the team and as a reference for the next round of changes.
Based on what you've checked so far, please compile a test report in the following format. --- ## Display Test Report **Date/time**: (today's date and time) **Test target**: https://xxx.myshopify.com **Change made**: (background of the check / what was changed) ### Results summary | Check item | Result | Notes | |---|---|---| | Homepage display | ✅ / ⚠️ / ❌ | | | Collection page | ✅ / ⚠️ / ❌ | | | Product detail page | ✅ / ⚠️ / ❌ | | | Cart interaction | ✅ / ⚠️ / ❌ | | | Responsive (mobile) | ✅ / ⚠️ / ❌ | | | Navigation | ✅ / ⚠️ / ❌ | | | Form | ✅ / ⚠️ / ❌ | | ### Issues found (If there are no issues, write "No issues") | Severity | Issue description | Affected page / location | |---|---|---| | 🔴 High | | | | 🟡 Medium | | | | 🟢 Low | | | ### Recommended actions (List the items that need fixing and the approach for each) ### Notes for the next check (Areas you couldn't check this time, and points to focus on in the next test) ---
The kinds of issues this finds
You may find issues that "were all green in Playwright."
A button can't be clicked due to z-index overlap
There are cases where the button exists in the DOM and the click event even fires, but on the actual screen another element is layered on top, leaving it unclickable. This is an issue you only notice once you look at a screenshot.
On mobile, the cart button is hidden behind the footer
A sticky footer can overlap the add-to-cart button, leaving it effectively unclickable on mobile. At desktop width there's no problem at all, and automated tests can't detect it either.
Font color blends into the background
With certain color schemes, the text color and background color can end up nearly identical. The text exists, so automated tests pass, but visually it's unreadable.
How to use it according to the scale of the change
Running every item every time raises the token cost, so it's practical to narrow the scope according to the scale of the change.
[Minor fixes (text, color changes, etc.)] -> Check only the relevant page with a check prompt [Adding/changing a specific block or section] -> Diff check prompt + responsive check [Large changes (header, footer, template changes)] -> Purchase flow check + responsive check + navigation check
We tried it with Claude and Codex
This is a comparison of giving the same prompt to Claude and Codex and running a mobile test on the same Horizon store.
Issues both found
On mobile, the regular navigation is still displayed and the header is tall (112px)
The "Home / Catalog / Blog / About / Contact" navigation is displayed alongside the hamburger menu, eating into the mobile above-the-fold area.
Issues only one of them found
| Codex | Claude (devtools-mcp as the main approach) | |
|---|---|---|
| Unique findings | The menu drawer width is 95% (356px), not full width Swatches are 22x22px, small as tap targets |
The collection listing is single-column. The "You may also like" on the PDP is two columns, so they're inconsistent The sticky ATC bar doesn't activate even when scrolling |
| Technical depth | — | The cart drawer runs as a native <dialog> (top layer), so z-index overlap accidents structurally can't happen |
| Horizontal scroll check | — |
Measured scrollWidth === viewport directly (no horizontal scroll) |
The "collection listing is single-column" observation appeared only in Claude's report. It isn't a bug but a design issue, and the angle of "the PDP recommendations are two columns but only the collection listing is single-column, so the experience is inconsistent" is a finding that brings in a UX perspective.
Regarding the cart drawer, Codex stopped at "displays OK," but Claude went as far as the native <dialog> top-layer structure and explained that "because it comes to the front without relying on z-index, overlap accidents are fundamentally impossible." Even with the same conclusion of "no issues," the depth of the reasoning differed.
How to use it alongside Playwright
Playwright is "a tool for confirming issues you already know about," while Claude in Chrome is "a tool for discovering issues you don't know about." Using Claude in Chrome for exploratory checks after a theme change, and Playwright for ongoing checks of "is this feature still working every time," works well as a division of labor. The realistic flow is to surface issues through exploration, then codify the flows you want to monitor regularly into Playwright.
Things to watch out for
Be careful with automated testing of the purchase flow
Automated testing from add-to-cart through checkout requires configuration changes to get around Cloudflare's bot detection. Applying that configuration broadly risks weakening the protection of the entire storefront, so it's realistic to test the purchase flow manually. With Shopify's Bogus Gateway (test payments), you can verify all the way to order completion without real card information.
It's no substitute for testing on real devices
Actual behavior on iOS Safari or Android Chrome is a different matter. Font rendering, scroll behavior, and the feel of tap target sizes can only be verified on real devices.
Summary
Having AI operate the browser to test your store moves you from "it seems to work, so it's fine" to a level of checking where you "actually look and confirm there are no issues."
It's especially suited to the exploratory check of "is anything looking off?" after a theme change. The same prompts work as-is with either Claude or Codex. Just change the URL to your own store and try working it into your post-change routine.