The same website can appear under several URLs without being several businesses

A URL is evidence of a web address. It is not, on its own, evidence of a separate business.

That distinction matters whenever a list of websites becomes a list of companies, prospects, locations, brands, or legal entities. Counting distinct URL strings can make a dataset look larger than it is. But removing apparent duplicates too quickly can create the opposite mistake: merging businesses that happen to share technical connections online.

The practical answer is to treat website cleanup and business-identity verification as two different jobs.

One site, many addresses

Consider four records found in a directory or prospect list:

• http://harbor.example
• https://harbor.example
• https://www.harbor.example/
• https://harbor.example/?utm_source=newsletter

These are four different URL strings. A URL can vary by scheme (http or https), host (www or no www), path, query string, or fragment. Yet all four may send a visitor to the same web experience.

This is not unusual. Search engines identify protocol variants, mobile and desktop variants, and URLs with tracking or filtering parameters as common sources of substantially duplicate pages. Analytics and search-reporting tools also offer domain-level views that span protocols and subdomains. Those features reflect a basic reality of the web: one web presence can be reached through many technical addresses.

So a count of unique URLs is not necessarily a count of unique websites. A count of unique hosts or domains is not necessarily a count of businesses either.

Group the web presence before deciding who operates it

Redirects and canonical declarations can help with the first question: do these observations belong to the same likely web property?

If http://harbor.example consistently redirects to https://www.harbor.example, that is strong evidence that the operator wants visitors to use the latter address. A 301 redirect, formally “Moved Permanently,” indicates that a resource has been assigned a new permanent URI.

A page may also declare a preferred version through a rel="canonical" link. Search engines treat redirects and canonical links as strong canonicalization signals. They are still signals, not absolute commands: Google can select a different canonical URL when the available evidence conflicts.

For data work, the key point is more modest. A redirect or canonical declaration supports grouping pages or URL variants into a website candidate. It does not prove that two company records refer to the same legal entity.

A retailer may redirect an older domain to a new store after an acquisition. A franchise, reseller, campaign site, or separately operated regional business may use a connected domain. Technical relationships are useful evidence, but they answer a technical question first.

A two-stage review avoids both errors

Start by preserving the URL exactly as it was observed. It records where the information was found and makes later review possible.

Then conduct a website-group review. Inspect the destination after any redirect, the host, the page purpose, and the declared canonical URL when one is available. Label the result carefully: “same web property candidate” or “same website candidate” is more accurate than “same company” at this stage.

Only after that should the business-identity review begin. Compare business-facing evidence such as:

• the stated site operator or legal notice;
• contact details, including telephone number and address;
• company or brand information on the site;
• official registration records where appropriate; and
• evidence that explains a relationship, such as a parent company, franchise arrangement, or regional subsidiary.

No single item should carry more weight than it deserves. A shared design, hosting provider, analytics pattern, or mailing address may suggest a relationship, but none alone establishes that two businesses are one entity.

Do not normalize away meaning

Query strings deserve extra care. A parameter such as utm_source=newsletter often identifies a tracking variant of the same page. But parameters can also control filters, product selections, language, session behavior, or other resource-specific functions.

For that reason, “remove every query parameter” is not a sound general rule. Check whether the variants reach the same destination and serve the same page purpose before grouping them. The same caution applies to trailing slashes, subdomains, and country-specific domains.

For example, support.example.com and careers.example.com may both belong to the same organization while serving distinct functions. Two country sites can have nearly identical branding and pages, yet be operated by separate local legal entities. Whether they belong in one analytical group depends on what the dataset is meant to measure.

Design records to preserve the distinction

A durable dataset separates the web observation from the identity decision. Useful fields include:

• observed URL;
• resolved or final URL;
• declared canonical URL, when available;
• website-group decision;
• business-identity decision; and
• an evidence note explaining why each decision was made.

This structure leaves room for uncertainty. A record can be confidently grouped with a web property while the operator remains unverified. It can also be linked to a business while remaining a distinct website section for content or functional analysis.

The goal is not to force every URL into one company record as quickly as possible. It is to count the thing the analysis actually claims to count. Separating website grouping from entity verification prevents inflated website totals—and prevents technically connected sites from being mistaken for one business without the evidence to support it.