Why do pages load for me but fail for Google?

Bot protection, firewall rules and rate limiting often treat crawlers differently than your warmed browser session. Only an outside request shows what Google sees.

What statuses disapprove products?

5xx errors, 404/410 dead pages, 403/401 blocks and 429 rate limits. Redirects do not disapprove outright but the feed should carry the final URL.

How many pages are checked?

Up to 12 product pages, fetched politely with concurrency limits so your server is not hammered.

Why does my product page load for me but fail for Googlebot?

Your browser and network may be trusted while an outside crawler request is blocked by a firewall, CDN rule, rate limit or server error. This check requests product pages from outside your network and reports the response it receives. It is not Googlebot itself, so compare the exact time and URL with your security logs and confirm the behavior in Search Console if Google reports a crawl issue.

What product page HTTP status codes cause problems?

A 404 or 410 means the page is not found or is gone; 401 or 403 denies access; 429 rate limits the request; and 5xx indicates a server error. Redirects can be valid, but a product feed should point directly to the final product URL. The exact effect depends on the destination and whether it is consistently available to crawlers.

How many product pages does this checker test?

It requests up to 12 product pages. The limited sample and concurrency controls are deliberate: they help identify reachability problems without issuing a large burst of requests. A clean result applies to the URLs checked at that time. If Merchant Center names a particular product that was not sampled, inspect its exact destination URL separately.

Should my product feed URL redirect?

A redirect does not automatically make a product unusable, but it adds another destination step and can send the crawler somewhere unexpected. Update the feed to the final URL for the same product whenever possible. Do not redirect an unavailable product to the home page or an unrelated item; remove or update the listing instead.

Can a 403 error stop Google Shopping from showing a product?

It can prevent a crawler from accessing the landing page, which can cause destination or availability issues. First determine which layer returns the 403: hosting access controls, a WAF, password protection, or another rule. Allow appropriate access to public product pages without broadly removing security controls, then recheck the URL from outside your network.

What your product pages return to Google

Your pages load fine in your browser. Google crawls them from somewhere else, and a 500, a block or a slow response there quietly disapproves the product. This checks them from outside your network.

Shipwork requests a set of your product pages the way a crawler would, and reports exactly what came back. Nothing is stored.

What the product page check tests

This check discovers product URLs from a store and requests up to 12 of them from outside your network. It records the HTTP response and reports pages that fail, redirect, or need attention. The requests are limited and run with concurrency controls so a check does not hammer the site. A successful response means the page answered this request; it does not certify every page or guarantee Googlebot receives the same response on every visit.

The distinction matters when your logged-in browser has a warm session or your office network is trusted by a firewall. An outside request can reveal a block or server failure hidden from you. Shipwork does not claim to be Googlebot itself, and a single check is a snapshot of the public response at that time.

Product page URLs discovered for the store, with up to 12 requested.
HTTP statuses including server errors, not found or gone responses, access blocks, rate limits and redirects.
The affected URL, response code, explanation and suggested next step.
A summary of pages requested, outright failures and warnings.

What each status means for a product URL

A 2xx response indicates the server returned a successful response to the check. It does not by itself prove the page contains the correct product, can be indexed, or matches your feed. A redirect means the requested address points elsewhere. That may be expected after a URL change, but a product feed should generally use the final product URL directly so the destination is clear.

A 4xx response usually means the URL is unavailable or access is denied. A 5xx response indicates a server-side failure. A 429 response means the server is rate limiting requests. Treat a timeout or transient failure as a reason to recheck and inspect server logs, not proof that the page is permanently broken.

404 or 410: confirm whether the product was removed; restore it or update links and the feed.
401 or 403: check password protection, access rules, bot protection and CDN policy.
429: review rate limits and allow legitimate search crawlers to fetch public product pages.
3xx: update the product URL at its source to point to the final destination.

Fix reachability problems without hiding the cause

Start with the exact URL and response shown. Open it in a private browser window and test from a different network. If both succeed while the outside check fails, ask whoever manages your CDN, WAF or hosting to review the request time and blocked request reason. Do not disable security protections globally as a first step; a narrow allow rule for public pages is safer than opening the whole site.

For a removed product, decide whether it should return. If it is permanently gone, serve the appropriate not-found response and remove or replace the stale URL in the feed and internal links. If the URL changed, redirect to the same product’s new page and update the feed to use that final address.

Example: https://example.com/products/blue-shirt returns 403 only to outside requests. Check the security layer’s rule log for that path before changing theme code.
For a transient 5xx, compare application and hosting logs with the report time, then rerun after the underlying error is fixed.
Use the feed check to review product data separately from URL reachability.
Use the broken links check to find broader internal URL failures.

When this check is useful

Run a product page check after changing URL handles, migrating platforms, changing a CDN or WAF rule, or installing an app that affects routing. It is also useful when Merchant Center reports a product destination problem even though the page opens for you. The result helps narrow the issue to the outside HTTP response rather than the product’s title, price or schema.

This is a sample of product URLs, not a complete crawl of every product. A clean report means the requested sample answered cleanly. If the reported Merchant Center item was not among the requested pages, inspect that exact URL yourself and use the related checks to investigate page content and data.

Feed check: titles, descriptions, price, image, brand, availability and duplicate titles.
Structured data check: product JSON-LD and its visible fields.
Site audit: broader crawl and technical findings across a set of pages.

Errors this check finds, and their fixes

Product page unavailable: When the page loads for you but returns an error to Google
Missing product page: What "Missing product page" means when the URL clearly exists

Questions

Why do pages load for me but fail for Google?: Bot protection, firewall rules and rate limiting often treat crawlers differently than your warmed browser session. Only an outside request shows what Google sees.
What statuses disapprove products?: 5xx errors, 404/410 dead pages, 403/401 blocks and 429 rate limits. Redirects do not disapprove outright but the feed should carry the final URL.
How many pages are checked?: Up to 12 product pages, fetched politely with concurrency limits so your server is not hammered.
Why does my product page load for me but fail for Googlebot?: Your browser and network may be trusted while an outside crawler request is blocked by a firewall, CDN rule, rate limit or server error. This check requests product pages from outside your network and reports the response it receives. It is not Googlebot itself, so compare the exact time and URL with your security logs and confirm the behavior in Search Console if Google reports a crawl issue.
What product page HTTP status codes cause problems?: A 404 or 410 means the page is not found or is gone; 401 or 403 denies access; 429 rate limits the request; and 5xx indicates a server error. Redirects can be valid, but a product feed should point directly to the final product URL. The exact effect depends on the destination and whether it is consistently available to crawlers.
How many product pages does this checker test?: It requests up to 12 product pages. The limited sample and concurrency controls are deliberate: they help identify reachability problems without issuing a large burst of requests. A clean result applies to the URLs checked at that time. If Merchant Center names a particular product that was not sampled, inspect its exact destination URL separately.
Should my product feed URL redirect?: A redirect does not automatically make a product unusable, but it adds another destination step and can send the crawler somewhere unexpected. Update the feed to the final URL for the same product whenever possible. Do not redirect an unavailable product to the home page or an unrelated item; remove or update the listing instead.
Can a 403 error stop Google Shopping from showing a product?: It can prevent a crawler from accessing the landing page, which can cause destination or availability issues. First determine which layer returns the 403: hosting access controls, a WAF, password protection, or another rule. Allow appropriate access to public product pages without broadly removing security controls, then recheck the URL from outside your network.