How to Remove index.php?route=common/home from the OpenCart Homepage

What does route=common/home mean in OpenCart?

OpenCart uses the route query parameter to direct a request to the appropriate controller. The official OpenCart URL library initially builds links as index.php?route=... and then allows registered rewrite handlers to transform them. See the official URL library source.

common/home is the homepage route. It is not a second business homepage, but it can become a second accessible URL when link generation or the rewrite layer does not consolidate it with the root.

Why does the duplicate URL appear?

• The logo, breadcrumb or a module generates a route-based link to common/home.
• A theme, extension, OCMOD or VQMod bypasses the expected URL rewrite.
• SEO URLs are enabled, but the homepage is not covered by the rewrite handler.
• The .htaccess file is inactive, misplaced or the server uses Nginx.
• Different stores, domains, languages or folders have different routing rules.

The official SEO URL startup controller rewrites known route/value pairs. When no mapping catches the homepage route, the query can remain. Review the official OpenCart SEO URL controller.

Is this a Google penalty?

Not automatically. It is still unnecessary duplication: it can split internal signals, create canonical and sitemap inconsistencies, complicate reporting and consume crawl activity on a URL you do not want to maintain. Google recommends consistent canonical signals and treats redirects as a strong consolidation signal in its canonicalization documentation.

Which URL should be canonical?

For a typical root installation, the canonical is the public homepage URL, such as https://example.com/. For a subfolder, multi-store or language setup, it may be /shop/, a separate domain or a localized root. Record the decision for every store and language before writing a redirect.

What should you inspect before changing anything?

1. Status code and complete redirect chain for the root and route URL.
2. Canonical tag and final resolved URL.
3. Source of internal links: logo, menu, breadcrumb, theme or extension.
4. XML sitemap, hreflang and language switcher.
5. Apache, LiteSpeed, Nginx or managed hosting and the active configuration.
6. OpenCart/PHP version, multi-store, subfolder, OCMOD/VQMod and caching/CDN.
7. Search Console, access logs and a crawl to identify real variants.

The safe order is source, redirect and then signal alignment.

1. Stop generating the duplicate. Update the logo, menu, theme or extension so new internal links point to the canonical root.
2. Add an exact redirect. The old route URL should reach the correct root through one permanent hop.
3. Align the signals. Self-canonical, sitemap, hreflang and internal links must agree.
4. Test and monitor. Crawl, logs, Search Console and real commerce flows after release.

Apache 2.4 example for a root installation.

This is a narrow example for Apache 2.4+, OpenCart installed at the root and the exact route=common/home query. Place it before OpenCart’s general catch-all rule. The QSD flag discards this exact query string and is defined in the official Apache RewriteRule flags.

RewriteCond %{QUERY_STRING} ^route=common/home$
RewriteRule ^index\.php$ / [R=301,L,QSD]

The exact match is deliberate: it does not silently discard language, UTM or other parameters. A subfolder needs a different target. Multi-store and separate language roots need their own decisions and tests. The official OpenCart .htaccess.txt documents the general SEO URL setup, not a universal homepage rule.

Nginx does not execute .htaccess.

The rule must be implemented in the active Nginx configuration by the server administrator or hosting provider. Avoid a generic copy-and-paste snippet: the safe solution varies by server, location, PHP upstream, subfolder and multi-store. The official Nginx rewrite module documentation explains directive execution order.

Multi-store, languages and subfolders need a route matrix.

A redirect to / can send a visitor to the wrong store or language. For every host or prefix, record the input URL, expected canonical, status and whether a parameter is functional. The language switcher should also point to a canonical localized URL rather than recreate common/home.

What about UTM, language and other parameters?

Do not remove all queries because one route is a duplicate. UTM parameters usually support attribution, language parameters can be functional and extensions may own others. Classify the parameters first, then choose exact matching or a controlled broader rule.

Is a canonical tag enough without a redirect?

A canonical helps, but when the duplicate does not need to remain accessible, a permanent server-side redirect gives users and crawlers a clearer outcome. Google recommends avoiding conflicting signals and describes permanent redirects for URL changes. A JavaScript redirect or meta refresh is not the right first choice here.

Cache, CDN and redirect caches can hide the result.

After the change, purge only the relevant layers and repeat the check without browser cache. Browsers and CDNs can retain a 301, so test in staging before production and keep an exact rollback. Cache purging is not a substitute for a correct rewrite.

Acceptance test: what should happen after the fix?

Also test the non-preferred protocol/host, trailing-slash policy, sitemap, canonical, hreflang, logo/menu links, product and category URLs, search, account, cart and checkout. The objective is not merely to hide one address; it is to protect every critical function.

When should you roll back?

Roll back if you see a loop, wrong store/language, loss of a functional query, changes to product/category URLs, problems in cart/checkout/account or a chain longer than one hop. Preserve logs and test cases so the next revision fixes the actual cause.

The most common mistakes are overly broad rules.

• Redirecting every index.php request and breaking functional routes.
• Using HTTP_HOST in a pasted rule without host validation.
• Discarding every query parameter without classification.
• Redirecting to another redirect instead of the final canonical destination.
• Pointing the canonical to the root while sitemap and logo still use the route URL.
• Changing production without backup, staging and checkout regression tests.

How does Firstidea approach this on a live OpenCart store?

We begin with a URL and server audit, identify what generates the duplicate, define a canonical matrix and apply the smallest safe change with rollback. If the issue belongs to wider technical debt, it enters a roadmap. Explore our OpenCart support service, OpenCart eShop development and SEO and organic growth service.

Frequently asked questions about OpenCart common/home.

Should I always remove index.php?route=common/home?

When it returns the same homepage as the root and has no separate function, consolidation is preferable. Confirm store, language and server setup first.

Does it affect SEO?

It can create duplicate and conflicting signals. It is not an automatic penalty, but should be resolved through consistent internal links, canonical, sitemap and redirect.

Should I use a 301 or 302?

Use a 301 or another permanent server-side status for permanent consolidation. Temporary behaviour can be useful during testing before the production rule is locked.

Is changing the canonical enough?

Not ideally. If the duplicate has no reason to remain accessible, correct the source of the links and add a permanent redirect while aligning every canonical signal.

Where should the Apache rule go?

Before the general OpenCart catch-all rewrite and only after confirming that this .htaccess is active. Back it up and adapt the target to the installation path.

Does the same rule work on Nginx?

No. Nginx does not read .htaccess. The logic belongs in the active server configuration and should be implemented by an authorised administrator.

What changes when OpenCart is installed in a subfolder?

The canonical target and RewriteRule path must follow the subfolder. Redirecting to / is wrong if the store homepage is /shop/.

What about multi-store?

Every domain or store needs its own expected root. A generic rule can send visitors to the wrong storefront.

Can I preserve UTM parameters?

Yes, but that requires logic different from the exact example in this guide. Separate tracking from functional parameters and verify the analytics result.

How do I find which module generates the URL?

Inspect rendered HTML, logo/menu/breadcrumb, theme overrides, OCMOD/VQMod modifications and extensions. A crawl with inlinks helps identify the source.

Should the duplicate be removed from the sitemap?

Yes. The sitemap should contain the canonical root, not the route URL. Apply the same policy to hreflang and important internal links.

How do I confirm the fix is safe?

Test status and chain, canonical and sitemap, run a crawl and regression-test products, categories, search, cart, checkout and account for every store and language.