A new website goes live. The pages look right, the forms work, the ads are running, and everyone moves on. A month later the ad report looks worse than it should. Clicks are coming in, but fewer of them are credited to the campaign that paid for them, and analytics shows a growing pile of visits with no source at all.

Nothing is broken that anyone can see. The site loads. The ads load the site. The problem sits in one small piece of the move that almost nobody checks: the www version of the address. We have found it on site after site we have migrated, most often on sites leaving Squarespace, and it is worth ten minutes of your time to look at your own.

What gets left behind when a site moves

Every website really has two front doors: the main domain (yourbusiness.com) and the www version (www.yourbusiness.com). When a site moves to a new host, the main domain gets pointed at the new site, because that is the address everyone tests. The www record is a separate entry in your domain settings, and it is easy to leave it pointing at the old host.

What happens next depends on the old host:

It shows a leftover page. On one site we moved, the www address was still serving the old host’s “coming soon” placeholder, marked so search engines would not index it. Anyone who typed www landed on a dead page.
It forwards to the new site. This one looks fine, which is why it survives. The old host sees a www visitor and sends them on to the main domain. The page loads, the address bar looks right, and a quick test passes.
It shows an error. The new host does not recognize the www address because nobody told it to expect one, so the visitor gets an error page instead of the site. We have also seen the error only on plain http://www, because the redirect rule was written for https and nothing else.

The first and third are easy to spot once you look. The second is the dangerous one.

How a working redirect can still lose your data

When someone clicks an ad, the link carries extra information after a question mark. Tags like utm_source and utm_campaign tell your analytics where the visit came from. Google Ads adds a click ID called gclid, which is how Google connects a later phone call, form or purchase back to the ad that produced it.

On one site we migrated, the old host’s forwarder kept the page path and some ordinary parameters, but silently dropped utm_source and gclid. So every ad click and every email link that used the www address arrived on the new site with its campaign tags removed. Analytics recorded the visit with no source. Google Ads could not match the conversion to the click. Nothing errored, nothing looked wrong, and the reports were simply incorrect.

The partial loss is what makes it hard to catch. If a redirect dropped everything, someone would notice. When it keeps some parameters and loses others, a casual test with the wrong tag passes.

Why it matters more than it sounds

Ad platforms make bidding decisions based on conversion data. When the click ID goes missing, the conversions that really happened are not credited to the ads that drove them. The campaign looks like it costs more per lead than it does, automated bidding learns from an incomplete picture, and the decisions that follow (cut this campaign, move budget there) are made on bad numbers.

A site that strips the click ID makes paid advertising look worse than it is. That can be the difference between keeping a campaign that works and turning it off. We wrote more about reading results honestly in Measuring What Your Marketing Actually Does.

How to check your own site

You do not need any special tools. Open a browser and type each of these, using your own domain:

https://www.yourdomain.com/?utm_source=test&gclid=test
http://www.yourdomain.com/?utm_source=test&gclid=test
http://yourdomain.com/?utm_source=test&gclid=test

For each one, look at where you land. You want three things:

You end up on your main address, in its https form.
Both utm_source=test and gclid=test are still in the address bar.
It happened in one step, with no error page or placeholder along the way.

Then try a page deeper than the home page, such as https://www.yourdomain.com/contact?utm_source=test, and confirm the path survives too.

If your site replaced an older one, check a few of the old page addresses as well, especially any that ads, emails or printed materials still use. Each should send visitors straight to the matching new page in a single hop, not bounce through two or three redirects first.

The fix

The fix is small, and it belongs in your domain or network settings rather than at the old host:

One redirect rule for www. Create a single permanent (301) redirect that sends both http and https versions of www to your main domain, keeping the full path and the query string. Many tools have a “preserve query string” option that is off by default. Turn it on.
Point the www record at the new host. Even with the redirect in place, the www entry should not depend on a host you no longer use. If the old account closes, the redirect goes with it.
Clean out the old records. Moves leave behind entries for the old host that serve no purpose and can cause confusion later. Remove the ones that belong to the previous platform, carefully, and leave anything related to email alone unless you know exactly what it does.

Afterward, run the same browser checks again. Then look at your analytics over the next few weeks: the share of visits with no source should drop, and campaign traffic should line up more closely with what the ad platforms report.

Make it part of every launch

This is not a one-time cleanup. Every time a site moves hosts, changes platforms or adds a new domain, the www address and the old URLs need the same check. It takes ten minutes to test and can save months of misread ad results.

If you want a second set of eyes on your redirects, tracking and the ad results built on top of them, our advertising and PPC team can take a look.