HikaShop generating duplicate product URLs with product ID

-- Browser(s) name and version -- : Chrome 154.0

Hi Nicolas,
We have noticed a new issue in Google Search Console after the recent changes related to HikaShop breadcrumbs.
Google has suddenly started discovering hundreds of alternative product URLs containing the HikaShop product ID, for example:
Correct URL: Alternative URL discovered by Google: Another example:
Correct: Alternative: The alternative URLs return HTTP 200 and HikaShop correctly outputs a canonical pointing to the clean URL, so Google currently reports them as “Alternate page with proper canonical tag”.
However, Google Search Console shows a large and recent increase in these URLs, and URL Inspection reports the clean product URL itself as a referring URL for the alternative URL.
This seems to indicate that somewhere on the product page HikaShop is now generating/discovering links using the format: instead of: This appears to coincide with the recent breadcrumb changes.
Could this be caused by the new HikaShop breadcrumb/router behaviour?
Ideally, we would like HikaShop to generate only the clean product URLs internally, without the product ID, while keeping our existing URLs unchanged.
Could you please check this before we modify anything on our side?
Thanks,
José Ángel

Hello José Ángel,

This is not caused by the breadcrumb changes. Those addresses are the addresses of your product variants, which HikaShop writes in the structured data (JSON-LD) of the product page when the "Include variants" option of the Google Products plugin is enabled. For example, the page www.hermanosgaliano.es/comprar/maquina-de-celo declares its two variants with the addresses /comprar/942-maquina-de-celo and /comprar/943-maquina-de-celo. Each of these addresses opens the page with that variant already selected, and its canonical tag points to /comprar/maquina-de-celo. That is why Search Console names the clean product page as the referring page.

This follows what Google asks for products with variants: each variant must be reachable at its own address that preselects it, and all of them share one canonical address. The status "Alternate page with proper canonical tag" is therefore expected and is not an error: Google indexes only the canonical page, and your existing URLs do not change. So you don't need to change anything.

If you would rather Google did not see these addresses, set "Include variants" to No in the settings of the Google Products plugin (Joomla > Extensions > Plugins, or HikaShop > System > Plugins). The product page will then declare a single product with its main address, and the product feed will only list the main products, without one entry per variant. If you send your products with variants to Google Merchant Center, keep it enabled.

Hi Nicolas,

Thanks, understood regarding the variant URLs. We will leave “Include variants” enabled.

While reviewing the Search Console warning, we have found a separate HikaShop issue. Google is discovering this URL:

www.hermanosgaliano.es/component/hikashop/product/listing

Google Search Console reports a server error (5xx) for it. The last Googlebot crawl was on October 4, and we have just run a live URL test today (October 7) and it still returns a server error (5xx) to Google.

Search Console reports several referring pages, including normal HikaShop/product pages, a filtered HikaShop listing and a HikaShop waitlist URL.

Since this is a /component/hikashop/product/listing URL, could you tell us why HikaShop is generating links to this route and what this URL should normally return?

Could this indicate that a HikaShop module/listing is generating the URL without the appropriate Joomla menu item / Itemid?

We have not added any redirect or changed anything yet, as we would first like to identify the source of the URL and the cause of the 5xx.

Thanks,
José Ángel

Hi,

The address /component/hikashop/product/listing does not come from the breadcrumbs or from a module. HikaShop writes it in a small piece of JavaScript on every page that has an add to cart or add to wishlist button: it is the page where the customer is sent after adding a product to their wishlist, when no notification plugin (such as "HikaShop cart notification") handles that action. On your product pages you can see it in the source as window.localPage.wishlistRedirect = function(...){window.location="/component/hikashop/product/listing";}. Google reads addresses found in scripts and tries them, which is why the referring pages are ordinary product, listing and waitlist pages. This code is old; Google only started to crawl that address recently.

That address is a product listing opened without a menu item, so it uses the default listing settings. On a standard HikaShop 6.6.0 installation it displays the products (HTTP 200), so the server error on your site comes from something specific to it (a template override of the listing, a module shown on that page, another extension...). We can't see the cause from outside: please set "Error Reporting" to "Maximum" in System > Global Configuration > Server for a few minutes, open www.hermanosgaliano.es/component/hikashop/product/listing , and send us the error message and the file and line it shows (or the matching lines of your server's PHP error log), then set Error Reporting back.

We have also changed HikaShop so that this redirection goes to the customer's wishlists, under a HikaShop menu item, as the add to cart redirection goes to the checkout. Once that change is in, with the next release, the address /component/hikashop/product/listing will no longer be written in your pages. Your existing URLs do not change.

Until then nothing breaks for your customers, and Search Console will keep reporting the address as long as it returns an error. If you prefer to silence it right away, you can redirect /component/hikashop/product/listing to your products listing page /hikashop-menu-for-products-listing/product/listing (for example with Joomla's Redirects component).

Hi Nicolas,

We ran the test with Error Reporting set to Maximum and found the cause of the HTTP 500.

The fatal error is:
Call to a member function get() on null

File:
/plugins/system/hikashop_ga4/hikashop_ga4.php
Line: 594

Before the fatal error, Joomla also reports:
Warning: Undefined variable $categoryClass
in the same file and line.

The failing line is:
$cat = $categoryClass->get($categoryId);

The stack trace shows the error originates in plgSystemHikashop_ga4->getCategoryInfo(), called from getCategoryJS() and then onBeforeCompileHead().

So it appears that the hikashop_ga4 system plugin is not initializing $categoryClass in this particular product listing context.

We have now restored Joomla Error Reporting to its previous setting.

Does this plugin belong to HikaShop, or should we contact its developer to have this case fixed?

Thanks,
José Ángel

Yes, "System - Google Analytics 4" (hikashop_ga4) is our plugin. The error you found is a bug in versions up to 1.5.1: in getCategoryInfo(), the category class was used before being loaded, so some listing pages (here /component/hikashop/product/listing, which falls back to the settings of one of your menu items) stopped with "Call to a member function get() on null". It was fixed in version 1.5.2 of the plugin, and the current version is 1.5.6.

Versions before 1.5.3 also had a problem with their update check, so Joomla probably never offered you the update. Please download the latest version of the plugin from its page on our marketplace ( www.hikashop.com/marketplace/product/108...egration-google.html ) and install it over the current one in System > Install > Extensions. Your settings are kept. Then open www.hermanosgaliano.es/component/hikashop/product/listing again: it should display the products instead of the 500 error, and Search Console will stop reporting it at its next crawl (you can ask for it with "Validate fix").

The Deprecated message about plgHikashopReminder::$db in your screenshot is only a notice from the Reminder plugin under PHP 8.2 and is not related to the error.