OpenCart Guide · 8 min read · Updated

“Crawled – Currently Not Indexed” and Every Other Search Console Page Indexing Reason, Explained for Online Stores (With OpenCart Fixes)

Every Search Console page indexing reason explained for online stores: which are normal, which cost you sales, and how to fix them in OpenCart.

Open Indexing > Pages in Google Search Console for almost any online store and the grey bar (“Not indexed”) is bigger than the green one. A store with 800 products might show 1,200 pages indexed and 9,000 not indexed, with fifteen different reasons. It looks alarming, and most of it is fine.

This post goes through each reason, says whether it’s expected, worth a look or a real problem for a store, and gives the fix, with OpenCart specifics where they apply. It’s for marketers and store owners who look at Search Console and want to know what to do about it.

First: filter to the pages you care about

The default view counts every URL Google has ever found, including sort orders, filters, old URLs and junk links from other sites. The question that matters is: are my product and category pages indexed?

  1. Submit an XML sitemap that lists only your real, canonical pages: products, categories, brands, information pages (free OpenCart 4 sitemap extension).
  2. In the Page indexing report, change the drop-down at the top from All known pages to All submitted pages, or pick your sitemap.

Now the numbers mean something. If 780 of 800 submitted products are indexed, you’re in good shape, whatever the “All known pages” view says. Click any reason and then a URL to inspect it; URL Inspection > Test live URL shows what Google sees now.

The reasons, one by one

Alternate page with proper canonical tag: expected

Google found the URL, saw a rel="canonical" pointing to another URL, and indexed that one instead. This is the system working. In OpenCart you’ll see lots of these:

  • Category pages with sort=, order= and limit= parameters. OpenCart’s category controller sets the canonical to the category without them.
  • Products reached through a category path: /laptops/macbook and /macbook show the same product, and the canonical points to one of them.
  • Tracking parameters (?utm_source=..., ?gclid=...).

Nothing to do, unless a URL here is one you want indexed, in which case its canonical is wrong.

Duplicate without user-selected canonical: worth a look

Google found several URLs with the same content, none of them had a canonical tag, and Google picked one itself. Check which pages these are:

  • Home page duplicates like index.php?route=common/home. Make sure the home page has a canonical to https://www.example.com/.
  • Information, manufacturer or special-offer pages in themes that don’t output a canonical. View the page source and search for canonical. If it’s missing, add it in the controller with $this->document->addLink($url, 'canonical'), which the header template outputs.
  • http and https or www and non-www versions both returning 200. Fix with a server-level 301 redirect to one version.

Duplicate, Google chose a different canonical than the user; worth a look

You said “this URL is the canonical”, Google disagreed. Usually because the pages really are near-identical: product variants as separate products with the same description (sizes, colours), or the same product in two languages without proper hreflang (see our hreflang and canonical guide). Either make the pages different (unique descriptions, images, specifications) or combine variants into one product with options.

Crawled – currently not indexed: a real problem if it’s products

Google fetched the page and decided not to index it, for now. This is a judgement on value, not a technical error. For stores, the usual causes:

  • Thin product pages. A title, a price, one photo and the manufacturer’s description that 200 other stores also use. Write your own descriptions, add specifications, real photos, reviews and answers to common questions.
  • Near-empty categories with one or two products.
  • Search, tag and compare pages that shouldn’t be indexed at all (see below).
  • A new or small site, where Google is cautious. Internal links from your home page and category pages, and links from other sites, help.

Click Validate fix after improving pages, but expect weeks, not days. Requesting indexing in URL Inspection for each URL doesn’t override the judgement.

Discovered – currently not indexed: worth a look

Google knows the URL exists but hasn’t fetched it yet. For a few pages, give it time. For thousands, Google is either deciding your site isn’t worth crawling faster, or it’s wasting its crawling on junk URLs:

  • Faceted filters. Every combination of filter, sort, limit and page creates a new URL: ?filter=12,15&sort=p.price&order=DESC&limit=100&page=7. Google discovers millions of them and spends its time there instead of on your new products. Make filter links rel="nofollow", or block the filter parameter in robots.txt (see the warning below).
  • A slow server. Google slows down crawling when your server is slow or returns errors. Check Settings > Crawl stats for response time; for OpenCart, caching and Core Web Vitals fixes help both visitors and Googlebot.

Excluded by ‘noindex’ tag: check it’s intended

The page has <meta name="robots" content="noindex"> or an X-Robots-Tag: noindex header. Fine for search results, account, cart and checkout pages. A problem if it’s on products, which usually happens because a staging site’s “noindex everything” setting was copied to production, or an SEO extension has a wrong rule. Look at the list.

Blocked by robots.txt: check it’s intended

robots.txt stops Google fetching these URLs. Normal for /admin, route=checkout/, route=account/ and similar.

The warning: robots.txt stops crawling, not indexing. A blocked URL that has links pointing to it can still be indexed, without content (“Indexed, though blocked by robots.txt”). And Google can’t see a noindex tag on a page it isn’t allowed to fetch. So pick one per URL type:

  • Don’t want it indexed? Allow crawling and use noindex (search result pages, tag pages).
  • Don’t want it crawled at all (millions of filter URLs eating crawl time)? Block it in robots.txt and make sure nothing important links there.

Our post on AI crawlers and robots.txt covers the file’s syntax.

Soft 404: a real problem

The page returns HTTP 200 but looks like an error or empty page to Google. Typical store causes:

  • Empty categories (“There are no products to list in this category”). Fill them, hide them, or redirect them to a parent.
  • Search results with no products.
  • Out-of-stock products. A product page that is still a full page (description, price, “Out of stock”, back-in-stock signup) is fine and usually shouldn’t be removed. One that has been stripped down to “This product is unavailable” looks like a soft 404. Keep the page useful, or 301 it to its replacement if it’s gone for good. Our back-in-stock notifications post shows how to keep sold-out pages working for you.

OpenCart already returns a real 404 status for disabled and deleted products and categories, which is correct.

Not found (404): usually expected

URLs that return 404. Removed products, old links from other sites, typos. Google reports them so you know, not because they hurt the site. Act on the ones that matter:

  • Products you replaced: 301 redirect to the new product, not to the home page.
  • Old URLs after a migration or SEO URL change: see our redesign redirect checklist.
  • 404s that you link to: fix the internal links.

Page with redirect: expected

The URL redirects somewhere else. Normal for old URLs and http to https. It’s only a problem if these URLs are in your sitemap (the sitemap should list final URLs) or if your internal links point to them.

Redirect error: a real problem

Google couldn’t follow the redirect: a loop (A to B to A), a chain that’s too long, a redirect to an empty or bad URL. Common after changing an OpenCart SEO keyword while a redirect extension still points the old URL to the new one and something points back. Test with curl -sIL https://www.example.com/old-url and follow each Location header.

Server error (5xx): a real problem

Your server failed when Google asked. A few during a short outage are harmless; a steady number means the server can’t cope, often because of aggressive bots and scrapers, an expensive filter query, or PHP errors on certain products (check System > Maintenance > Error Logs). If bot traffic is the cause, our Cloudflare security guide for OpenCart shows how to rate-limit it, but don’t block Googlebot.

Blocked due to unauthorized request (401) or access forbidden (403)

Pages behind a login, or a firewall rule that blocks Googlebot. If they’re public pages, look at your WAF and security plugin rules; some block requests by user agent or by “suspicious” country, which can include the countries Google crawls from.

What OpenCart stores should usually keep out of the index

URL patternWhat to do
route=product/search (search results)noindex, allow crawling
route=product/product&...&tag= and tag search pagesnoindex
route=product/comparenoindex or block
route=account/, route=checkout/, route=affiliate/Block in robots.txt
Filter combinations (filter=)nofollow links and/or block, unless you’ve built indexable filter pages on purpose
sort=, order=, limit=Leave to the canonical tag
page=2 and beyondLeave indexable with a self-referencing canonical. Don’t canonicalise every page to page 1, or products only linked from later pages become hard to find

A weekly ten-minute routine

  1. Pages report, submitted pages only. Is the indexed number steady or growing as you add products?
  2. New reasons. Search Console emails you when a new issue type appears; open those first.
  3. Server error, redirect error, soft 404. Any new URLs? These are the ones that are actually broken.
  4. Crawled – currently not indexed, for products. Pick five and improve them: better description, more images, internal links from a relevant category or blog post.
  5. After fixing a group, click Validate fix and note the date.

Pair it with the checks in our technical SEO checklist for marketers, and Search Console becomes a to-do list instead of a wall of grey.

Rupak Nepali
Written byRupak Nepali

Author of four Opencart book.
The recent are Opencart 4 developer book and Opencart 4 user manual

Leave a Reply

Your email address will not be published. Required fields are marked *