Web Development Company in Pune: Duplicate URLs, Canonical Tags and www vs non-www — How to Make Sure Google Indexes One Version of Every Page

Web Development Company in Pune: Duplicate URLs, Canonical Tags and www vs non-www — How to Make Sure Google Indexes One Version of Every Page

Your website probably answers to more addresses than you think. The same page can load at http and https, with and without www, with and without a trailing slash, and with tracking parameters tacked on by every ad you run. To Google, each of those can be a separate URL. The fix is to choose one preferred address for every page, redirect the alternatives to it, add a self-referencing canonical tag, and keep your internal links and sitemap pointing at that same address. A good web development company in Pune sets this up at launch; if yours did not, you can check and repair it in an afternoon using the steps below.

This guide is for business owners, marketing managers and in-house developers who run a WordPress, Shopify, WooCommerce or custom site and want to know whether duplicate URLs are costing them anything. It explains what duplicates are, how to test your own site without special tools, which fixes are safe, and which popular "fixes" make things worse. It is not a promise of rankings. Canonical hygiene removes a source of confusion; it does not replace good content.

What a duplicate URL is, and why Google cares

A URL is a duplicate when it serves the same content, or nearly the same content, as another URL on your site. Google's documentation on consolidating duplicate URLs explains that duplicates are normal on the web and that Google groups them into a cluster and picks one as the canonical, meaning the version it will show in search results. The problem is not a penalty. The problem is that you let Google choose, and it may choose a version you did not intend: the http page, the one with a tracking parameter, or the www version when your ads and business cards use the bare domain.

Here is what that looks like in practice for a Pune clinic whose site lives at example.in:

• http://example.in/services/
• https://example.in/services/
• https://www.example.in/services/
• https://example.in/services
• https://example.in/services/?utm_source=facebook&utm_campaign=diwali
• https://example.in/services/?sort=newest (on a page that has a sort control)

That is six addresses for one page. Every one of them can be crawled, and any of them can collect links, shares and clicks. When signals such as backlinks spread across several versions, none of them looks as strong as it could if they were all counted against one. Duplicates also waste crawl effort on larger sites, because Google spends visits on copies instead of on new pages.

There are four common sources of duplicates on small business sites:

1. Protocol and host variants. http versus https, and www versus non-www.
2. Trailing slash and case variants. /about versus /about/, and in some servers /About.
3. Parameters. Tracking tags (utm_, gclid, fbclid), sorting, filtering and session identifiers.
4. Genuinely similar pages. Printer-friendly versions, category pages reachable by two paths, a product reachable in several categories, and near-identical location or service pages.

The first three are technical and fixable once. The fourth is a content decision, and we cover it near the end.

How Google chooses a canonical

Google's guidance describes several signals that work together. In order of strength, the documentation lists:

• Redirects. A permanent redirect is a strong signal that the destination should be the canonical.
• The rel="canonical" tag. A link element in the page head, or an HTTP header, naming the preferred URL. Google describes this as a strong signal too.
• Sitemap inclusion. A weaker signal. Listing a URL in your sitemap suggests you consider it canonical.

Google also states that it looks at the content itself, so a canonical tag does not force the outcome if the pages are clearly different, and it may pick a different canonical if your signals disagree. This is the key practical lesson: your signals must agree. If the sitemap lists the www version, the canonical tag names the non-www version and your menu links to a third variant, you are asking Google to guess.

Google also prefers https over http by default, but that preference can be overridden by an invalid certificate, an https page that canonicalises to http, or an https page that redirects back to http. So the first job is making sure https is clean.

Step 1: Test what your site does today

You do not need a paid tool. Open a private browser window and try these in turn, noting where each one ends up (look at the address bar after the page loads).

1. Type http://yourdomain.in with no www.
2. Type http://www.yourdomain.in.
3. Type https://www.yourdomain.in.
4. Type https://yourdomain.in.
5. Take any inner page, such as your services page, and load it with and without a trailing slash.
6. Add ?test=1 to the end of an inner page and load it.

What you want to see: the first four all land on the same final address, and each redirect happens in a single step. What goes wrong most often:

• Two of the four load without redirecting, so both versions are live copies.
• The http version redirects to https, but to the wrong host (for example, http://www goes to https://non-www, then on to https://www). That is a chain, which is slow and unnecessary.
• Both trailing-slash versions load without redirecting.

To see the redirect status code, use your browser's developer tools (Network tab) or run curl -I https://yourdomain.in/services from a terminal. A permanent redirect shows as 301 or 308. A temporary one shows as 302 or 307. Google's documentation says permanent redirects are a strong canonical signal and temporary ones a weaker one, so for host and protocol fixes you want permanent.

Then check what Google has already decided. In Google Search Console, open the URL Inspection tool, paste an inner page address, and compare "User-declared canonical" with "Google-selected canonical". If they differ, you have a conflict worth understanding. Also open the Page indexing report and look for the reasons "Duplicate without user-selected canonical", "Duplicate, Google chose different canonical than user" and "Alternate page with proper canonical tag". The last one is usually harmless: it means a variant correctly points to the main page. The first two deserve a look.

Step 2: Choose your preferred version

You have to make two decisions once and then stick to them.

www or non-www? Google's documentation does not say one is better; it says pick one and redirect the other. The practical differences are small. A www hostname is easier to move behind a content delivery network or a different server later because a subdomain can use a CNAME record, while a bare domain has restrictions at the DNS level. A bare domain is shorter on printed material. Whichever your business already uses on its Google Business Profile, ad accounts, email signature and printed material is usually the sensible choice, because it keeps your existing links consistent. If you are starting fresh, either is acceptable.

Trailing slash or none? Again either is acceptable; consistency matters. On WordPress, the default is a trailing slash on pages. On many JavaScript frameworks and static hosts, it depends on configuration. Pick the version your platform produces by default and make the other redirect to it.

Write both decisions down in a one-line note, for example: "Preferred: https://yourdomain.in/ with trailing slash." Anyone who later touches the site, whether a freelancer or a new agency, can then follow the same rule.

Step 3: Redirect everything else, once

The goal is that every non-preferred variant sends a permanent redirect straight to the preferred address in a single hop. On an Apache server, that is typically a few lines in the .htaccess file. On Nginx, it is a server block. On managed platforms such as Shopify, the host and https redirects are handled in the admin (Domains settings), and you mostly need only to set the primary domain correctly. On WordPress, the Site Address and WordPress Address settings should both use the preferred https address, and a security or caching plugin sometimes adds its own redirect that conflicts with the server's; two systems redirecting differently is a common cause of loops.

Common mistakes at this step:

• Redirect chains. http://www to http://non-www to https://non-www takes two hops when one would do. Each hop slows the visitor slightly, and long chains risk being abandoned. Google's documentation says its crawler follows a limited number of hops, so keep to one.
• Redirect loops. Two rules that each send visitors to the other's version produce the "too many redirects" error. If you see it after a change, undo the last rule and test one thing at a time.
• Temporary instead of permanent. A 302 is the default in some tools. Check the code.
• Forgetting the certificate. Every hostname you redirect from needs to serve a valid certificate first, otherwise a visitor on the old host sees a browser warning before the redirect happens. Make sure the certificate covers both the bare and www hostnames.

After changing redirects, test all six scenarios from Step 1 again, and test a few inner pages, including a deep page, a blog post and a page with a query string.

Step 4: Add a self-referencing canonical tag to every page

A canonical tag is a single line in the <head>:

<link rel="canonical" href="https://yourdomain.in/services/" />

Google's guidance for this tag is specific, and each rule prevents a real error:

• Use an absolute URL, including the protocol and hostname, not a relative path. Relative values are easy to get wrong.
• Put the tag on the preferred page too. A self-referencing canonical on the main page confirms the choice and also covers every parameter variant, because a copy of the page carrying ?utm_source=... will repeat the same tag naming the clean address.
• Use one method. Use the HTML tag or the HTTP header, not both with different values.
• Put it in the HTML the server sends. If a page is built in the browser by JavaScript, the canonical should be in the initial HTML, not injected later, since a changed canonical can be ignored or misread.
• Never point to a redirecting or erroring page. The canonical target should return 200.
• One canonical per page. Plugins sometimes add a second tag on top of the theme's tag. View the page source (right-click, View Page Source) and search for canonical. You should find one.

On WordPress, a good SEO plugin writes self-referencing canonicals automatically; your job is to check that the theme is not adding a second one. On Shopify, canonical tags are generated by the theme (look for canonical_url in the theme's head section). On a custom build, make the canonical a function of the page's clean route, not of the incoming request URL, which is how a tracking parameter ends up inside the canonical by mistake.

Step 5: Handle parameters deliberately

Parameters cause the largest numbers of duplicates, especially on stores.

Tracking parameters (utm_source, utm_medium, gclid, fbclid) do not change the content. The self-referencing canonical on the clean page deals with them: the page loads with the parameter so analytics works, and the canonical tag tells Google which address to keep. You do not need to block them in robots.txt, and blocking is a mistake for a specific reason: Google's guidance warns against using robots.txt for canonicalisation, because a blocked URL can still be indexed without its content, and Google cannot see the canonical tag on a page it is not allowed to fetch. Keep UTM tags consistent as well, because they are a separate problem for reporting. Our guide to UTM tracking and campaign naming covers that side.

Sorting and filtering parameters are more delicate. A sort order (?sort=price) shows the same products in a different order, so canonicalising to the unsorted page is usually right. A filter that creates a genuinely different set of products people search for (for example, "cotton kurtas" within a category) may deserve its own indexable page with its own title and content, while a filter combination nobody searches for should not be indexed at all. That is a design decision with trade-offs, covered in our guide to faceted navigation and SEO for online stores.

Session identifiers in URLs are a legacy problem. If your platform appends a session ID to the address, ask your developer to move it to a cookie.

Note that the old URL Parameters tool in Search Console was retired by Google, so you cannot rely on it to tell Google how to treat parameters; the on-page and redirect signals above are what is left, and they are sufficient.

Step 6: Make your internal links and sitemap agree

Google's documentation lists, among the mistakes to avoid, linking internally to duplicate URLs instead of the canonical, and naming different canonicals for the same page in different places. After redirects and tags are in place, audit these two things:

• Internal links. Menus, footers, buttons and blog links should all use the preferred address. A site that redirects /services to /services/ but links to /services everywhere makes every click pass through a redirect. Search-and-replace in the database (carefully, with a backup) or fix the menu and theme templates.
• Sitemap. Your XML sitemap should list only canonical, indexable, 200-status URLs, using the preferred protocol, host and slash style. If the sitemap lists the http version or redirected URLs, it is working against your canonical tags. Most WordPress SEO plugins generate this automatically, but confirm by opening /sitemap.xml and spot-checking five entries.

Our guide to planning your website structure and sitemap goes further on keeping a sitemap clean as a site grows.

Step 7: Deal with genuinely similar pages

Technical fixes cover the same page at different addresses. The harder case is different pages with almost the same content.

• A product in several categories. Let it have one primary URL, for example /products/cotton-kurta/, and let categories link to that rather than creating /women/kurtas/cotton-kurta/ and /sale/cotton-kurta/ copies. Most platforms handle this correctly by default; some themes create category-path URLs, in which case the canonical should name the primary one.
• Printable or AMP-style alternates. If you have a separate print version, canonicalise it to the main page.
• Near-identical service or location pages. Pages that differ only by a place name are not helped by a canonical; they need real differences or consolidation. We cover this in our guide to service-area pages without doorway pages.
• Old and new versions after a redesign. Redirect each old URL to its closest new equivalent, not all to the home page. A redesign that skips this is the most common cause of lost traffic; see our website redesign versus rebuild guide for planning this.

A canonical tag across genuinely different pages tells Google two things are the same when they are not, and Google may simply ignore it.

Mistakes that make things worse

Some commonly suggested "fixes" cause problems:

1. Canonicalising every page to the homepage. This tells Google your whole site is one page. Google will usually ignore it, but you have thrown away a clean signal and may confuse the pages in the process.
2. Using noindex to pick a canonical. Google's documentation lists this as a mistake. A noindex tag removes a page from search; it does not tell Google to prefer another version.
3. Blocking duplicates in robots.txt. As above, Google cannot read a canonical tag on a page it cannot crawl.
4. Using the Removals tool to clean up duplicates. It hides URLs temporarily and can hide all versions of the page.
5. Canonical pointing at a redirected URL. The canonical should be the final destination.
6. Pointing https pages at http. This can cause Google to prefer the insecure version.
7. Leaving a staging site open. A copy of your site on a development address, with the same content and no protection, is the most expensive duplicate of all. Put staging behind a password and add noindex there. See our guide to staging, deployment and rollback.

How long until you see an effect

Google recrawls at its own pace. After you fix redirects and canonicals, expect the Page indexing report to take several weeks to reflect the changes for most pages, and longer on large sites. Request indexing in URL Inspection for your most important five or ten pages, and leave the rest to normal crawling. We cannot give you a ranking figure, because there is not one that applies to every site: some sites with severe duplication see visible changes, and many sites with minor duplication see none. The value is mostly in removing an uncertainty and in keeping your reporting clean, since analytics will show one URL per page instead of several.

A fifteen-minute checklist

1. Test the four host and protocol variants and the trailing-slash variants; all should end at one address in one hop with a 301 or 308.
2. View the source of your home page and one inner page; confirm exactly one absolute self-referencing canonical.
3. Open your sitemap; confirm it lists only preferred, working URLs.
4. In Search Console, check "Google-selected canonical" for five important pages.
5. Check the Page indexing report for "Duplicate, Google chose different canonical than user".
6. Check that menus and footer links use the preferred URLs.
7. Confirm staging and old domains are blocked or redirected.
8. Write down your preferred format and share it with whoever edits the site.

Canonical tags tell Google which version of a page you prefer; they do not keep a page out of search. For that, see our guide to robots.txt, noindex and staging sites, which explains when to block, when to noindex and when to use a password.

Frequently Asked Questions

Does Google penalise duplicate content?

For ordinary technical duplicates such as www and non-www or tracking parameters, Google generally treats them as something to consolidate rather than punish. The cost is lost clarity: signals can be split and Google may pick a version you did not want.

Should I use www or non-www for my website?

Either works. Google's documentation says to pick one and redirect the other. Choose the version your business already uses on its Google Business Profile, ads and printed material, and keep it consistent everywhere.

Is a canonical tag the same as a 301 redirect?

No. A redirect sends visitors and Google to the other address. A canonical tag leaves both addresses reachable but tells Google which one to treat as the main version. Use redirects when the duplicate has no reason to exist, and canonical tags when a variant such as a tracking link must keep working.

Do I need a canonical tag on every page?

It is good practice to give each indexable page a self-referencing canonical with an absolute URL. Google will pick a canonical itself if you do not, but a self-referencing tag also covers parameter variants of the page.

Why does Search Console say Google chose a different canonical than I did?

It means Google's signals disagree with yours. Common causes are conflicting sitemap and tag values, internal links to another version, a redirect, or two pages that are genuinely too similar. Inspect the URL, compare the two canonicals, and align the redirect, tag, sitemap and links.

Sources

• Google Search Central, "What is URL canonicalization" and "How to specify a canonical URL with rel=canonical and other methods" (developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls), for signal strength, absolute URLs, https preference and the mistakes list.
• Google Search Central, "How HTTP status codes, and network and DNS errors affect Google Search" (developers.google.com/search/docs/crawling-indexing/http-network-errors), for how permanent and temporary redirects are treated.
• The six-URL example, the fifteen-minute checklist and the advice on choosing www or non-www are our own working guidance, not figures from Google. Behaviour can change, so check Google's current documentation.

About the author and next step

This guide was written by the web development team at Govindani Infotech, a website design and development company at 2nd Floor, Landmark Plaza, 206 Satara Road, Parvati Paytha, Pune 411009. If you would like us to check your redirects, canonical tags and sitemap, see our website creation service and SEO service pages, or contact the team on 092019 58274. Scope and pricing are confirmed by the team after looking at your site.