“Should we use the old Google pixel after a domain move?” sounds like one configuration question. It actually combines several systems: website redirects, search ownership, indexing signals and analytics collection.
When we moved the GaaS marketing site from versaunt.com to trygaas.com, we kept those jobs separate. This article records the technical checks completed on September 7, 2026 and turns them into a practical checklist. It does not claim that the migration has already increased rankings, search traffic or leads.
Separate the systems before changing them
| System | Job in the move | Evidence to check |
|---|---|---|
| Registrar and authoritative DNS | Control domain records and ownership verification | Actual nameservers and public DNS responses |
| Hosting and redirects | Serve the new site and route old URLs | HTTP status, destination and final page |
| Search Console | Verify properties and report search processing | Ownership status, sitemap receipt and migration state |
| GA4 | Collect observed website activity into a property | Intended stream, tag behavior and received events |
| Lead delivery | Receive inquiries after the visitor arrives | Accepted business-system outcome |
Moving one layer does not automatically configure the others. A working 301 redirect does not install an analytics tag. A verified domain does not prove that a form works. A sitemap receipt does not mean every listed page is indexed.
Find the authoritative DNS provider
In our case, the site was hosted on Vercel while the authoritative DNS remained at Porkbun. That distinction mattered because adding a verification record in the wrong control panel would not have published it where Google's DNS check looked.
Read the actual nameservers before editing records. Then add the exact verification value to the active DNS zone without replacing unrelated records. Email routing, SPF, certificate validation and web-hosting records have their own jobs.
We added the Search Console TXT record and checked the public DNS answer. Existing nameservers, web records and email-related records were preserved. The useful completion evidence was the published answer followed by Google's ownership verification, not merely the record appearing in a registrar form.
Keep the verification record after the initial success. It is part of the ownership setup, not a temporary installation note to delete during cleanup.
Map old pages to the corresponding new pages
A domain move should preserve a visitor's intent where an equivalent page exists. Someone opening an old article should reach its corresponding article, not be sent to the homepage simply because the brand changed.
Google's migration guidance describes preparing a URL mapping, using redirects, updating canonical annotations and internal links, and monitoring both old and new URLs. It also advises expecting processing and ranking fluctuations during a move. Google's site-move documentation.
For the GaaS checks, sampled old URLs returned a single 301 to the corresponding trygaas.com path, followed by a 200 response. The sample included the homepage and several subpages. That verified those paths at that time; it was not a claim that every historical URL had been individually checked.
Use a broader inventory for your own migration: current sitemap URLs, important landing pages, known linked resources, campaign destinations and any retired or consolidated content. Decide the correct destination for each category. Do not create a redirect to unrelated content just to avoid every 404.
Inspect the final page, not only the redirect
A redirect can work while the destination is wrong. Check the final status, canonical URL, indexability, visible content and relevant next step.
For a public resource page, the final URL should not unexpectedly ask a logged-out visitor to sign in. For a planned or incomplete tool, keeping it out of the index can still be the right choice. A migration is not a reason to make unfinished pages indexable.
Check query handling when campaigns rely on parameters. Preserve legitimate attribution information where appropriate, while keeping sensitive values out of analytics collection. The UTM convention guide explains how to separate campaign naming from internal navigation measurement.
Also inspect canonical host variants. A preferred canonical signal and a redirect are different mechanisms. Record which behavior your site uses and verify that the page's metadata agrees with the intended public address.
Verify both search properties and submit the new sitemap
Our new domain property was verified through its DNS provider. Search Console accepted the trygaas.com sitemap and reported 633 discovered pages at that checkpoint.
The word “discovered” matters. It describes the submitted inventory and processing state we observed. It does not establish that 633 pages were indexed, ranking, receiving impressions or attracting visitors.
We also confirmed Google's Change of Address flow from the old domain to the new one. The interface reported that the site was moving, with a September 7, 2026 start date. The new property's search reports were initially processing.
Record those receipts with dates. A later reviewer should be able to distinguish the migration being initiated from the migration being fully reflected in search results. Keep the old property available so its reports and any remaining old-URL activity can be inspected during the transition.
Decide whether analytics continuity is the right goal
We retained the existing GA4 property and web stream, renamed the stream for GaaS, and updated its website URL to trygaas.com. That preserved the historical property while collecting new public-site activity into the same reporting context.
This was a continuity decision for the same business and its marketing site. It was not an attempt to transfer a search ranking through a measurement ID. Redirects and search signals serve a different purpose from analytics collection.
Before making the same choice, inspect who owns the current property, which business it represents, what historical data it contains and whether its configuration is suitable. A landing-page template copied from an unrelated site should not keep sending traffic to someone else's analytics property.
Write down the intended account, property and stream in a private operating record. Public guides do not need to publish internal account identifiers or verification values for readers to understand the method.
Validate pageviews and the public/private boundary
Our implementation loads the Google tag on production public marketing routes. It excludes local development, preview hosts and private product routes, and respects the browser opt-outs implemented in the site. URL collection keeps bounded campaign attribution while removing arbitrary contact or authentication query values.
We checked initial pageview behavior and client-side navigation so one page transition would not be counted twice by overlapping mechanisms. The stream's automatic history pageviews and form interactions were adjusted to match the explicit implementation; other existing enhanced-measurement settings were retained.
Those choices describe our implementation, not a universal prescription for every site. A traditional multi-page site, a consent-managed storefront and a single-page application can need different configurations. The important check is that the actual collected events match the intended definitions without exposing private data.
Check the conversion path after the move
Search visitors still need a working next step. Inspect product links, account creation, contact routes, calendar links and form delivery. A moved domain can reveal dependencies that were previously hidden behind a working old URL.
Keep the milestones separate. Clicking a button, attempting a form, receiving an accepted server response and qualifying a lead are different events. If the business relies on a form, verify the delivery contract without sending unnecessary synthetic inquiries into a live sales workflow.
Use a handover checklist to assign ownership for the domain, hosting, tags, forms and downstream systems. A migration is easier to operate when each dependency has a named owner.
Keep a launch log with limits
A useful migration record contains:
- Old and new domains, with the intended canonical host.
- The URL-mapping rule and any exceptions.
- DNS ownership verification and the date it was checked.
- Redirect samples or a full crawl report with final destinations.
- Sitemap submission status and the exact meaning of its counts.
- Search Console migration status.
- Analytics property decision and event-validation evidence.
- Lead-path checks and unresolved dependencies.
- The release date and a follow-up reporting window.
For GaaS, the launch record supports the technical statements in this article. Search processing and commercial outcomes require later evidence. We have deliberately not turned a successful verification dialog into a case study about traffic growth.
Review the move as data matures
After launch, compare old and new URL activity, indexing reports, relevant landing pages and measurable inquiries. Annotate other changes that occur during the same period. If the team also publishes content or changes a call to action, the before-and-after comparison cannot isolate the domain move's effect by itself.
Use the AI search measurement guide for provider visibility and referral distinctions, and the reporting template to keep definitions consistent. The goal is a usable record of what moved, what works and what remains unknown while search systems and visitors adjust.