Website Migration SEO Checklist: Moving to GoHighLevel

This is part three of a five part series on SEO inside GoHighLevel. Part two covered launching a brand new site. This one is harder, because you already have something to lose.

I have watched businesses move onto GoHighLevel and lose sixty percent of their organic traffic in a fortnight. Every single time, the platform got the blame and every single time it was not the platform. It was a migration done without a redirect map.

A migration is a controlled operation. Done properly you lose a little traffic for two to four weeks while Google recrawls, then recover and usually exceed the old baseline because the new site is faster and better structured. Done badly you start again from zero.

Here is the protocol, then the nine mistakes.

The anatomy of a migration traffic loss

Four things carry your rankings: the URL, the content, the internal link structure, and the signals pointing at that URL from elsewhere. A migration threatens all four at once, which is why it is the highest-risk thing you can do to a site that is already working.

Build your baseline first

Before you touch anything, capture what you have. You cannot tell whether a migration went badly if you never knew what good looked like.

Export from Google Search Console:

Pages report, last 12 months, all pages with impressions. This is your priority list.
Queries report, last 12 months. These are the terms you are protecting.
Sitemaps, and the full list of indexed URLs from the Coverage report.

Crawl the existing site. Screaming Frog's free tier handles 500 URLs, which covers most small business sites. Export every URL, title tag, meta description, H1 and status code. This one CSV is the backbone of the entire migration.

Export from Analytics: landing pages by sessions for the last twelve months, so you know which pages actually earn money rather than just impressions.

Note your backlinks. Any URL with external links pointing at it is precious. Losing it is losing the authority those links carry.

Save all of it somewhere you will still be able to find it in three months. Now you can migrate.

Mistake 1: Changing URL structures without a 301 map

This is the one that causes the disasters. Every other mistake on this list is recoverable in an afternoon. This one is not.

When you rebuild in GoHighLevel it is tempting to tidy up. /services/commercial-plumbing-services-fort-worth becomes /commercial-plumbing. Cleaner, better, and it just orphaned every ranking, link and bookmark attached to the old address.

You may absolutely change URLs. You may not change them without redirecting.

Build the map

Take your crawl export and add two columns: new URL and status. Every old URL gets one of three fates:

Kept identical. Best case. Nothing to do.
Redirected 301 to the closest equivalent. Most URLs land here.
Deliberately retired, redirected to the most relevant parent page rather than the homepage.

That last point matters. Redirecting everything to the homepage is treated as a soft 404 and passes almost nothing. Redirect a retired service page to the services hub, not to /. If there is genuinely no relevant destination, let it 410 and move on.

Set them up in GoHighLevel

Go to Sites > URL Redirects > Add Redirect. Enter the source path and the target, and choose the redirect type. Use 301, permanent, for anything that has ever ranked. A 302 tells Google the move is temporary and it will hold onto the old URL.

GoHighLevel supports bulk CSV upload for redirects, which is the only sane approach past about twenty rules. Two columns, source and destination, upload, verify. It also supports wildcard patterns, useful when a whole directory moves as a unit, for example /blog/ to /articles/.

New in August 2026: unpublish a single page, with the redirect built in

GoHighLevel now lets you take one page offline inside a funnel or website without touching the domain. This changes how migrations and clean-ups are handled, because the redirect is part of the unpublish flow rather than something you remember to add afterwards.

Open the funnel or website, go to the page list (or the pages side panel inside the builder), open the page's Options menu and choose Unpublish. You then pick what visitors hitting that URL get:

a standard 404 page,
a redirect to another page in the same funnel or website, or
a redirect to any external URL.

Things worth knowing before you use it on a live site:

Your domain is untouched. Unpublishing one page does not disturb the SSL certificate or DNS, which kills the old habit of disconnecting a whole domain just to hide one landing page.
It is instant and reversible. No full-funnel republish, and the page stays editable so you can publish it again later.
You can change the destination later. Options > Edit Redirect Link repoints the traffic without changing the publish state.
No redirect means a 404. If you leave the destination blank the system falls back to a default 404 page, so on any URL that has ever ranked, set a destination deliberately.
A/B tests stop automatically when you unpublish a page in the test. Historic metrics and stats are preserved.
Unpublished pages disappear from navigation pickers, so buttons and image navs cannot link at something that is offline.
Status is visible everywhere. The page list and step sidebar show an Unpublished tag, and the builder header shows a live status chip with the page URL and who last changed it, which is useful when several people work in the same sub-account.

For a migration this is the tidiest way to retire a legacy page you rebuilt elsewhere: unpublish it, point the redirect at the replacement, and the link equity keeps flowing while the original stays editable in case you got the mapping wrong. It is not a substitute for the site-wide 301 map in Sites > URL Redirects, though. Use redirects for old-domain and cross-site rules, and page-level unpublishing for pages that live inside the funnel or website you are working in.

Details that bite

Trailing slashes. Decide on one convention and enforce it. /services and /services/ must not both resolve independently.
Case. Old sites often have mixed-case URLs. URLs are case sensitive. Map them explicitly.
Query strings. If old pages ranked with parameters attached, confirm they survive the redirect.
Redirect chains. If the old site already redirected A to B, and you now redirect B to C, point A directly at C. Chains leak authority and slow down crawling.

Test before cutover, not after

Take your redirect map, feed the old URL list into a bulk status checker, and confirm every single one returns a single 301 landing on a live 200 page. Do this on launch day, within the hour. Not next week.

Mistake 2: Leaving legacy metadata behind

Your old title tags and meta descriptions were often written and refined over years. Rebuilding in GHL and typing fresh ones from memory throws that away.

You already exported them in the crawl. Copy them across. In GoHighLevel that is Page Settings > SEO Meta Data for each page.

The same goes for heading hierarchy. If the old page had one H1 and six H2s covering specific subtopics, replicate that structure. Designers rebuilding in a visual editor routinely use heading elements purely for text size, and you end up with four H1s and no logical outline. Google reads the outline.

If you want to improve the metadata, improve it later. Migrate first, optimise second, so that if something moves you know which change caused it.

Mistake 3: No canonical tags

GoHighLevel does not enforce self-referential canonicals for you the way most CMS platforms do. On a funnel builder, where duplicating a page is a two-click operation, this matters more than usual.

Set an explicit canonical on every indexable page, pointing at itself, in Page Settings > SEO Meta Data > Canonical URL. Use the full absolute URL, https and all.

Where this saves you:

A page reachable at both /services and /services/
Ad variants of a page that are near-identical to the original
Pages reachable under both a temporary GHL preview domain and your live domain
URLs with UTM parameters attached, which are extremely common in this ecosystem

Without canonicals, Google picks a winner for you, and it frequently picks the wrong one.

If you are keeping content live on another domain, for example syndicating to Medium, the canonical on the syndicated copy should point back at your version. Otherwise you are handing them the ranking.

Mistake 4: Breaking analytics, pixels and GTM

Losing tracking during a migration is doubly bad, because now you cannot measure whether the migration worked.

In GoHighLevel, tracking code lives in two places:

Global: Sites > Websites > Settings > Tracking Code, applied across the site. This is where GA4, Google Tag Manager and your Meta pixel belong.
Page level: Page Settings > Tracking Code, for anything that should only fire on one page, such as a conversion event on a thank you page.

Migrate them in this order:

1. Install GTM globally in the head section and let it carry everything it can. 2. Install GA4 directly if it is not already inside GTM. 3. Install conversion pixels, and re-point conversion events at the new thank you page URLs. This is the step everyone forgets, and it silently kills ad optimisation. 4. Reconnect Search Console, ideally as a domain property so the verification survives future changes.

Then verify. Load the site, use Google Tag Assistant or the GTM preview, submit a real form, and confirm the conversion fires. Do not assume from the fact that you pasted the code.

Mistake 5: Broken assets and orphaned custom code

Every image on the old site had a URL. If your new pages reference the old ones, they break the moment the old host goes away.

Re-upload media into the GoHighLevel media library rather than hotlinking your old host. While you are re-uploading, compress and convert to WebP. Migration is the cheapest possible moment to fix image weight, and image weight is usually the single biggest speed problem on the old site.

For custom CSS and JavaScript, be ruthless. Most of what accumulated on a WordPress site was compensating for theme limitations that no longer exist. Rebuild with native GHL elements where you can and keep only the custom code you can explain. Every leftover script is a render-blocking request you inherited for no reason.

Check for hardcoded absolute URLs in any code you do keep, including old domain references in link hrefs, form actions and script sources.

Mistake 6: Leaving funnel duplicates indexed

This is the mistake unique to funnel builders, and it appears a few weeks after launch when you have stopped paying attention.

You duplicate a landing page to test a new headline. The duplicate inherits the indexing setting of the original, which was indexable. Now two near-identical pages compete for the same query and Google is unimpressed by both.

Rules I follow:

Any duplicate created for testing is noindexed at the moment it is created, not later.
Any ad-specific landing page is noindexed by default, because it exists for paid traffic.
Every page gets a self-referential canonical, so if a duplicate does slip through, the signal still resolves.
Retire a duplicate by unpublishing it rather than deleting it. Since the August 2026 Single Page Unpublish update you can take one page offline from its Options menu and send its traffic to the page that should have won, keeping the historic data and the ability to bring it back.
Once a month, run site:yourdomain.com in Google and skim the results. Duplicates are obvious in that view and it takes ninety seconds.

Mistake 7: DNS and SSL mishandled on cutover day

Preparation makes this a non-event.

A week before cutover, drop the TTL on your existing DNS records to 300 seconds. TTL controls how long resolvers cache the record. If yours is set to 24 hours and you change it on the day, some visitors will be pointed at the dead old server for a full day. Lowering it a week in advance means the change propagates in minutes.

On cutover day, update the records, then wait for GoHighLevel to issue the certificate. There is a window between DNS resolving and SSL provisioning where the site serves certificate warnings. It is usually short. Plan for it by cutting over at a low-traffic hour rather than on Monday morning.

Do not cancel the old hosting immediately. Keep it running for at least thirty days. If something is missing you will want to look at the original, and if the DNS change needs reverting you will want somewhere to revert to.

After cutover, raise the TTL back to something normal, an hour or more.

Mistake 8: Not resubmitting sitemaps

The new site has a new sitemap, at yourdomain.com/sitemap.xml. Google does not know that.

On launch day:

1. Load the new sitemap and confirm it lists the pages you expect and none of the funnel plumbing. 2. In Search Console, submit the new sitemap. 3. Leave the old sitemap submitted for a few weeks. Counterintuitive, but it encourages Google to recrawl the old URLs, which is how it discovers your redirects. Remove it once the old URLs stop appearing. 4. Use URL Inspection and Request Indexing on your ten most important pages. Manual, tedious, and it meaningfully speeds up the first wave. 5. Repeat the whole thing in Bing Webmaster Tools.

Mistake 9: Ignoring the post-migration signals

The first four weeks are where you catch problems while they are still cheap.

Week 1

Check the Coverage report daily for a spike in 404s. A cluster of 404s means a gap in the redirect map. Cross-reference against your old URL export and add the missing rules.
Confirm your top twenty pages are indexed via URL Inspection.
Verify tracking is firing on real traffic, not just in preview.

Week 2

Expect impressions to dip. A ten to thirty percent drop is normal while Google reprocesses. A drop over fifty percent is a redirect problem, not a settling-in period.
Compare the Pages report against your baseline export. Any page that had impressions before and has zero now is a page to inspect individually.

Week 3

Rankings should be stabilising. Run the GHL on-page audit and clear whatever it finds.
Check page speed on your top landing pages. New sites are usually faster, but a heavy hero video or an unsized calendar embed can undo that instantly.

Week 4

Compare like for like against your baseline. You are looking for recovery to roughly ninety percent or better of the old impression volume.
Anything still down after four weeks needs a specific diagnosis. Nine times out of ten it is a redirect chain, a missing canonical, or content that got quietly shortened during the rebuild because a designer thought a paragraph looked untidy.

That last cause deserves its own warning. Rebuilding in a visual editor tempts everyone to trim copy for aesthetics. If a page ranked with 1,800 words and now has 600, it did not lose rankings because of GoHighLevel. It lost rankings because you deleted the reason it ranked.

The one-page checklist

Before: export Search Console pages and queries, crawl the old site, note top landing pages and backlinks, lower DNS TTL, build the full redirect map.

During: replicate metadata and headings, set self-referential canonicals, migrate tracking code globally, re-upload and compress media, noindex all funnel plumbing, load the redirect CSV.

After: test every old URL for a single clean 301, submit both sitemaps, request indexing on the top pages, verify tracking with a real submission, and watch Coverage and the Pages report weekly for a month.

Do that and a migration is a two-week dip. Skip the redirect map and it is a rebuild of everything you spent years earning.

Part four moves from technical protection to offence: local SEO, heatmaps, Google Business Profile and multi-location setups inside GoHighLevel.