Merchant Center Says “Unable to Check Product Pages” — But Your Store Works?

 


Merchant Center Says “Unable to Check Product Pages” — But Your Store Works?

You click the product URL.

It opens instantly.

The image loads.

The price is there.

You can add the product to cart.

But Merchant Center says:

Unable to check product pages

or:

Product page unavailable

That can feel completely illogical.

If the page works for you, how can Google say it doesn't?

Because:

“I can open the page in Chrome”

and:

“Google's crawler can reliably access the same page”

are not always the same test.

Before changing your product feed, I would find out exactly where Google's crawl is failing.

Start With the Exact Crawl Error

Go to:

Merchant Center → Products → Needs attention

Open the affected issue.

Don't stop at the top-level warning.

Look for the actual crawl error attached to the affected products.

You may see something related to:

  • page not found

  • robots.txt

  • too many redirects

  • connection failure

  • mobile landing page

  • server error

  • hostname or DNS problems

Those are very different problems.

If the issue is:

404

I wouldn't start editing robots.txt.

If it is:

Blocked by robots.txt

I wouldn't rewrite the product title.

The error type should determine the investigation.

Open the Exact URL From Merchant Center

This is the first thing I would test manually.

Copy the exact URL Google has for the affected SKU.

Do not navigate to the product through your homepage.

Do not search for the item through your store.

Open the actual submitted URL.

For example, you may think Merchant Center is using:

/products/classic-hoodie

while the feed actually contains:

/products/classic-hoodie-old

The first URL works.

The second returns:

404

That explains the issue immediately.

Also check whether the URL contains:

  • old product handles

  • tracking parameters

  • country parameters

  • variant IDs

  • redirects

  • mobile-specific URLs

A working store does not guarantee that every URL inside your product data still works.

Then Test It in a Private Window

Your normal browser can hide problems.

You may already be:

  • logged in

  • carrying store cookies

  • in an allowed region

  • using a cached page

  • past an age or consent screen

So open the exact product URL in an incognito/private window.

Ask:

Can a completely new visitor see the product immediately?

A product landing page submitted to Merchant Center should not require someone to:

  • create an account

  • sign in

  • complete another action just to see the product information

If your product data is only visible after a login, Google may not see the same page you do.

Check robots.txt

This is one of the most important checks when Google says it can't inspect product pages.

Your site may be accidentally telling crawlers:

Do not enter.

Open your site's:

/robots.txt

and check whether important product paths are blocked.

Google specifically uses crawlers such as:

Googlebot

for pages

and:

Googlebot-Image

for product images.

If either is blocked from important product content, Merchant Center may not be able to complete its checks.

This sometimes happens after:

  • website migrations

  • staging-site rules being copied into production

  • SEO plugin changes

  • developer work

  • bot-blocking changes

The storefront may still work perfectly for humans.

The crawler is the one being refused.

Watch the Redirect Chain

Another problem that looks invisible to a normal visitor is redirects.

Imagine the feed submits:

oldstore.com/product123

which redirects to:

www.oldstore.com/product123

which redirects to:

newstore.com/products/product123

which redirects again to:

newstore.com/products/classic-hoodie

Your browser may follow the chain so quickly that you barely notice.

Google Merchant Center is less tolerant of a messy landing-page path.

Google's current guidance says product landing pages should not go through more than two redirects.

So if the page “works” but Merchant Center says unavailable, check whether the original submitted URL is taking a long route before reaching the real page.

The cleaner fix is usually:

submit the final product URL directly.

Check Desktop and Mobile Separately

This one is easy to overlook.

Your desktop page may work perfectly.

Your mobile version may not.

Merchant Center routinely checks product pages using both desktop and mobile crawling.

A mobile problem can therefore affect the product even if you only ever test it from your computer.

Try the same exact URL on a phone or with a mobile browser environment.

Look for:

  • blank page

  • redirect loop

  • broken mobile template

  • blocked scripts

  • missing product information

  • unavailable mobile URL

The submitted product page needs to work reliably across devices.

A Temporary Server Error Can Still Matter

Suppose you open the page at 4:00 PM.

It works.

Google crawled it at 2:00 AM.

At 2:00 AM your server returned:

503 Service Unavailable

Both observations can be true.

This is similar to the price mismatch issue we discussed earlier:

what you see now is not necessarily what Google saw when it checked.

If Merchant Center reports a connection or server problem, look at:

  • hosting uptime

  • server logs

  • CDN logs

  • recent deployment history

  • 5xx errors

One isolated outage may resolve.

Repeated crawler failures point to a reliability problem.

Don't Ignore DNS or Hostname Problems

A page can also become unreachable because the hostname itself cannot be resolved correctly.

For example, after:

  • changing DNS provider

  • moving hosting

  • changing domains

  • editing CDN configuration

some visitors may reach the site while others temporarily fail.

Merchant Center can report hostname resolution errors when Google's systems cannot resolve the submitted domain.

If this started after a website migration, I would put DNS near the top of the investigation list.

Make Sure You're Using the Verified Domain

Check the domain in the product URL.

It should match the website domain associated with your Merchant Center account.

For example, if your Merchant Center account is verified for:

yourstore.com

but the feed suddenly sends users to:

anotherstore.com

that can create a problem.

The same applies after:

  • rebranding

  • moving to a new domain

  • changing ecommerce platforms

  • using a third-party product page

Don't assume the new website configuration automatically updated every product URL already stored in Merchant Center.

One Pattern I Would Take Seriously

Suppose:

3 products

show the crawl error.

That may be three bad URLs.

But if:

3,000 products

suddenly show the same issue on the same day,

I would stop inspecting SKUs one by one.

That usually points me toward something shared across the site:

  • robots.txt changed

  • hosting problem

  • CDN or firewall change

  • domain migration

  • redirect configuration

  • mobile template issue

The number of affected products is diagnostic information.

Use it.

What I Would Not Do First

If Merchant Center cannot crawl a landing page, I would not immediately:

  • rewrite product titles

  • change GTINs

  • change prices

  • rebuild the entire feed

  • delete and recreate the Merchant Center account

None of those repairs a page that Google cannot access.

The first goal is simpler:

Can Google's crawler reliably reach the exact submitted product URL?

If the answer is no, fix that first.

My Quick Check

If I saw this error, I'd work through this order:

Exact Merchant Center URL

Does it really open?

↓

Incognito test

Can a new visitor see it without logging in?

↓

robots.txt

Are Googlebot and Googlebot-Image allowed?

↓

Redirects

Is the URL bouncing through several locations?

↓

Mobile

Does the page work on mobile too?

↓

Server / DNS

Was the site unavailable when Google checked?

↓

Verified domain

Does the submitted URL still belong to the correct Merchant Center website?

That usually narrows the issue down much faster than editing the feed blindly.

If You Want to Check the Product Page First

Mingche can check three public product URLs from the same store for product-page signals including:

  • price

  • availability

  • variants

  • structured data

That doesn't replace a server-log or robots.txt investigation.

But it can help answer an earlier question:

“Can this product page be accessed and interpreted normally from the public web?”

Check up to 3 Product Pages for Free →

If the public page works but Google still reports crawl problems, move deeper into:

robots.txt → redirects → mobile access → hosting → DNS → Merchant Center URL configuration.

Bottom Line

When your product page works for you but Merchant Center says it can't check it, don't assume Google is simply wrong.

You and Google's crawler may be reaching the page under very different conditions.

Start with the exact URL.

Then follow the access path:

Merchant Center URL

→ redirects

→ robots.txt

→ server

→ mobile / desktop

→ final product page

The problem usually becomes much clearer once you stop asking:

“Does my website work?”

and start asking:

“Can Google reliably reach the exact product page I submitted?”

Disclaimer

Mingche is an independent product-data readiness service and is not affiliated with or endorsed by Google.

Product-data auditing or correction does not guarantee approval, visibility, ranking, traffic or sales. Google independently determines Merchant Center eligibility and how products appear across its services.

Comments

Post a Comment

Popular posts from this blog

Before you upload a product feed: check the row, the variant and the page

A product file can look tidy and still describe the wrong offer. The useful question is whether each row points to the product a customer can actually buy, at the price and availability you submitted. Start with a copy of your catalog export. Keep the original and record when it was exported. The following is a short review workflow for English product data and US-dollar offers. It is a starting point, not a complete Merchant Center compliance checklist. First confirm which file you are checking A current-looking spreadsheet can still cover only a selected set of products, or differ from the file Merchant Center last received. Keep the export time and the source version with your notes. Working from Shopify: use the export selection and coverage checklist to distinguish the rows you selected from the full catalogue. A Shopify export is source evidence, not automatically a ready-to-upload Google feed. The file looks right but an issue remains: check the last file Merchant Center ac...
Read more
Image
  Merchant Center Says “Missing Brand” — Should You Use Your Store Name? You open Merchant Center and see: Missing brand The obvious fix seems easy. Your store is called: YourStore So you type: Brand: YourStore Save. Done? Not necessarily. The brand field is supposed to describe the brand of the product , not simply the company selling it. That distinction matters. Before changing hundreds of products, I would first figure out which of these situations you are actually in: You sell another company's product. You manufacture the product yourself. You sell a private-label product. The product genuinely has no recognized brand. Those four situations should not automatically receive the same value. First: Ask Who Actually Branded the Product Imagine your store sells a pair of Adidas shoes. Your business is called: YourStore The correct brand is not: YourStore It is: Adidas because that is the product brand shoppers recognize. Google's current brand specification says the value sho...
Read more

Before importing a repaired product CSV, ask for the change log

A repaired CSV should come with an explanation of what changed. Otherwise, you are being asked to upload a file without knowing whether it fixed a formatting problem or silently guessed a product fact. Keep the original export. Before importing any proposed replacement, review a change log that lets you trace a changed field back to the same product and its evidence. This is an illustrative workflow, not a customer case study or a promise that every field can be repaired. Prepared with AI assistance by Rowmint, the product-data education brand of Mingche Commerce. Three rows, three different decisions Example issue Evidence available Appropriate next step A field contains accidental surrounding spaces The receiving field's rules and the intended value are known Propose a supported formatting correction; show old and new values A product identifier is missing No manufacturer record supplied Request the source identifier or relevant product evidence; do not invent digits The lin...
Read more