Shopify SEO check

Shopify SEO check: a worked Shopify study

An example of Shopify SEO check. Replace the figures with your own before you decide.

Key takeaways

  • A second Product node can contradict the buy box.
  • Matching the price stops the contradiction. It does not create a ranking.
  • Rerun the check after a theme publish or a schema app.

What you would do

Say you just published a theme. The buy box says $42. A review app still sends a product price of $39. The checker flags the mismatch. Fix that extra price before you write more content. A crawler can quote the price the shopper never sees.

Once the prices match, you have stopped contradicting yourself. You have not “won SEO.” Open an assistant from the result and ask about that URL if you want to see what it says today. Name, price, and availability is the detail. The SEO check is what you rerun after the theme or the app changes.

Before you change the store

These are examples. Run the tool on your own URL or your own costs. That result is the one to act on. Do not put an example in a deck as if it were your store.

A product page that says two prices

Say the hero product is a 30ml vitamin C serum. The buy box shows $42. The Shopify SEO check shows a Product node at $42 and a second node at $39. The page looks finished in the browser. The second node is the bug.

You search the page source for 39. It sits in a block the review app added, using a compare-at or a stale price from when the serum was on sale. The theme’s own block is the $42 that matches the button. The fix is the app’s schema setting, not a new paragraph of copy and not a disallow in robots.txt.

You turn the extra schema off, publish, and run the check on the serum URL again. One price remains, and it matches the button. Availability says in stock, and the size you sell is in stock. That is the pass. You still do not know whether the serum ranks for “vitamin C serum.” You know a crawler is no longer being offered a cheaper product than the shopper.

A robots.txt edit that went too far

Say someone wanted the store out of AI training and pasted a disallow that included Googlebot. Search traffic drops the following weeks. The check, or a direct look at robots.txt, shows Googlebot blocked on the product path. Google’s documentation treats Googlebot as the Search crawler. The training control is Google-Extended, which Google says does not affect Search ranking or inclusion.

The repair is to allow Googlebot again and to put the training decision on Google-Extended only, if a training opt-out is actually what you want. Publish, open robots.txt, and confirm the two tokens say what you think. Then request indexing for the hero URL in Search Console if it fell out. The check cannot file that request for you.

The same story can happen with OAI-SearchBot. Blocking it opts the store out of ChatGPT search. That may be what you want. It is not what you want if the person who edited the file thought they were only blocking training. GPTBot is the training crawler. Read the names before you leave the file published.

A clean result that should not change the plan

Say the collection URL you hoped would rank is readable, the products in the grid have names and prices, and robots.txt is open to Googlebot. The check is clean. The collection still sits on page three. Do not add a fake FAQ of keywords to the bottom of the template. The check did not ask you to.

Look at the collection itself. Does it answer the query with products a shopper can buy, or is it a thin grid of the same title repeated? Are the products in stock? Is the page linked from the navigation? Those are merchandising and internal-link questions. They are the next work. The clean check means you can stop blaming schema for a while.

Write that down so the next meeting does not reopen it. “Schema matched on the date you checked. The ranking question is the collection, not the markup.” Then work on the collection: the products in the grid, the internal links, and whether the title matches what a shopper came to buy. Those are edits you can see. Another schema pass on a clean URL is not.

A market redirect that looks like a bug

Say you run the check from a network that the store sends to the EU market. The price comes back in euros. Your ad is in dollars. The result looks wrong and is describing a different market than the ad. Open the US URL if the store gives you one, or run the check from a US path, and compare like with like.

If both markets are real, both offers should be coherent inside their own pages. The EU page should not show a euro price in the button and a dollar price in the data. That is a bug. The EU page showing euros while you remember the US price is not a bug.

Note the market on the result when you send it. A developer who “fixes” the EU price back to dollars will break the market you just verified.

Availability on a product with more than one variant

Say the serum has a 30ml that is in stock and a 50ml that is not. The buy box follows the selected variant. The structured data has to do the same, or it has to describe an offer that is honest about both. A single availability of OutOfStock because one size is gone will hide the size you can still sell. A single InStock because one size remains will invite a click onto the size you cannot sell.

Open the variant your ad uses. Compare the button with the offer in the check. Then switch the variant on the page and, if the data is in the HTML as separate offers, compare that one too. If the theme only prints the first variant, a shopper who lands on the second can see a price the data never mentioned. That is a theme limitation to know about. The practical fix is to make the landing URL select the variant you described, and to keep that variant’s data accurate. Put the variant in the URL when the ad names a size. A URL that always opens the first variant will keep disagreeing with the ad no matter how carefully the description is written.

Sold-out behavior is a merchandising choice. You can hide the variant, show it as unavailable, or take a pre-order. Pick one and make the button, the data, and the ad agree. A pre-order button with InStock in the data is the same class of bug as a dollar mismatch. It tells two stories about whether the shopper can have the product now. Fix the story before you write another line of description. The description is not where this bug lives.

Shopify questions

Is this from a real store?

No. It is an example, so you can see the decision. Run it on your URL or your numbers before you change anything.

What should I do with my own result?

Write down the one change it justifies, make that change, and rerun the same URL or the same inputs. Measure the business effect somewhere the tool cannot see: Analytics, the ad account, or the invoice.