Understanding the types of duplicate content that actually affect rankings — and separating them from the types that don't matter: Duplicate content that genuinely affects rankings falls into two categories. Internal duplication: the same content appearing at multiple URLs within your own website. This happens via www vs. non-www variants (both example.com and www.example.com serving identical content), HTTP vs. HTTPS variants, trailing slash vs. no trailing slash (example.com/services/ and example.com/services), CMS-generated paginated pages with near-identical content, tag and category archive pages that duplicate post content, and location pages that are templates with city names swapped into identical text. External duplication: your content appearing verbatim on other websites. For most local businesses, this is a minor concern — Google generally identifies and credits the original source. The duplicate content types that most commonly suppress local service business rankings are internal: template-generated location pages that differ only by city name, and multi-channel CMS publishing that creates the same page at multiple URL paths. Diagnose your current duplicate content exposure using Screaming Frog's 'Duplicate Pages' export (compares MD5 hash of all page content) and Google Search Console's Coverage report, which often surfaces duplicate content issues as 'Duplicate without user-selected canonical' warnings.

The canonical tag — what it actually does, how to implement it correctly, and the most common mistakes that make it ineffective: The canonical tag is an HTML element placed in a page's head section that tells Google which version of a URL should be treated as the 'official' version. When you have a page accessible at multiple URLs (say, with and without trailing slash), the canonical tag on both versions points to the single preferred URL: <link rel='canonical' href='https://www.example.com/services/' />. This tells Google to consolidate ranking signals (links, engagement metrics, historical authority) to the canonical URL rather than splitting them across multiple versions. Common mistakes that make canonical tags ineffective: (1) Canonical tags that conflict with redirects — if the page redirects to URL B but has a canonical pointing to URL A, Google will ignore the canonical. (2) Canonical chains — Page A canonicals to Page B, Page B canonicals to Page C. Google follows the chain but only the final destination matters. (3) Canonical tags on noindex pages — Google can't canonicalize to a page it's not indexing. (4) Self-canonicals that aren't self-consistent — every page should have a canonical tag pointing to itself as the preferred URL to prevent future duplicate issues. Verify your canonical implementation using Screaming Frog's 'Canonicals' export or Ahrefs' site audit, both of which surface canonical inconsistencies, conflicts, and chains across your entire site.

How thin location pages become duplicate content — and the content depth that differentiates them enough to rank independently: The most common local SEO duplicate content problem isn't a technical URL variant — it's a set of template location pages where only the city name differs. A plumbing company with 8 city pages that are all '500 words of identical service description with [City] inserted in 4 places' has created a duplicate content set that Google typically resolves by picking one to index and ignoring the others. To rank independently, each location page needs genuinely differentiated content that passes a basic uniqueness test: if you replaced the city name and geography references with placeholder text, could you still tell which city the page was written for? A Gilbert location page that references Power Ranch, the hard water issues from the Gilbert water supply, and the new-construction plumbing patterns in the Cooley Station area passes this test. A template page with 'plumber in Gilbert AZ' inserted into generic text does not. The minimum differentiation: 2 to 3 genuinely unique content sections per page that address the specific location's characteristics, housing stock, local service considerations, or competitive context. Semrush's Content Audit tool and Copyscape both surface near-duplicate content issues across your site and can benchmark your pages against each other before Google has to make that judgment.

Redirects vs. canonical tags — when to use each and the most common mischoice that wastes link equity: Choosing the wrong duplicate content resolution method is itself an SEO error. Redirects (301 redirects) physically move users and Googlebot from one URL to another and transfer nearly all link equity to the destination. Use redirects when the duplicate URL has no ongoing value and you want to permanently consolidate it into the canonical. Canonical tags don't move users — they're a crawl directive only. Use canonical tags when you need the duplicate URL to remain accessible for functional reasons (printer-friendly pages, AMP versions, dynamic filter pages) but want to prevent it from splitting ranking signals. The common mischoice: using canonical tags instead of 301 redirects for old pages with existing links. A 301 redirect on an old URL transfers its link equity to the new page. A canonical tag on the same old URL tells Google which page to prefer but doesn't eliminate the old URL from the web — any links pointing to it still go there. For legacy URL migrations and page consolidations, 301 redirects produce better ranking outcomes than canonical tags alone. Verify redirect chains and orphaned canonical tags using Screaming Frog's 'Redirects' and 'Canonicals' exports.

Managing duplicate content during a site migration is a critical SEO preservation task that most non-specialist web designers get wrong: Website migrations — moving to a new platform, redesigning with new URL structures, consolidating multiple sites, or migrating from HTTP to HTTPS — are among the highest-risk duplicate content events in local SEO. When a site migration creates new URLs for existing content without redirecting old URLs to new ones, Google encounters both the old URLs (which have accumulated ranking signals) and new URLs (which have none) simultaneously. The result is either splitting the ranking signal between old and new versions, or abandoning the old URLs' accumulated equity entirely when they eventually 404. A properly executed migration maps every old URL to its exact new URL equivalent with a 301 redirect, verifies the redirects are working correctly (no redirect chains, no redirect loops), resubmits the sitemap to Search Console, and monitors crawl data closely for the 30 to 90 days following launch. Migrations handled this way preserve ranking signals and typically show full traffic recovery within 60 to 90 days. Migrations handled without proper redirect mapping often take 6 to 12 months to recover.