After a WordPress Move: Check Search Traffic, the Old Host, and Renewals

The new site opens and the migration tool reports completion, so canceling the old host can feel like the next step. Yet the old environment may still provide email, DNS, redirects, or downloadable files. The new site may have passed only a home-page check while form notifications and recent data remain unverified. Closeout means resolving each of these remaining dependencies.

Think of the closeout document as a handover record: which service moved, who verified it, what still needs to stay, and when payment can stop. This guide begins after cutover and does not repeat the file-copy procedure. It focuses on observable evidence so you can retire old services with confidence and assign ongoing care for the new site.

Record the cutover time and comparison baseline

Write down the actual cutover date, time zone, primary URL, old and new hosts, and the scope of changes. Did you only change hosts, or also change the domain, layout, or form provider? Each scope calls for different observations. Without this baseline, a traffic change several days later is hard to interpret because you may not remember which settings changed together.

Save the pre-migration list of key pages, results of important function tests, and available traffic and error logs. Compare matching time periods and conditions; weekdays differ from weekends, and promotion days from ordinary days. If you also changed analytics tools or tag settings, note that too, so a measurement change is not mistaken for a real loss of visitors.

1. Create a cutover log with the time, URL, and every item changed together.
2. Keep verification baselines for the home page, popular posts, forms, and download pages.
3. Assign someone to review results daily and provide a contact for failure of key functions.

Check functions before traffic curves

Start with what visitors actually do: open a post, search the site, download a file, submit a form, or complete a required login. Check on a phone and different networks, not only your usual browser. Record the URL, time, action, and result for each test, and keep reproducible steps for failures.

Compare logs from old and new hosts to confirm production traffic is gradually served by the new environment. When requests still reach the old site, identify whether they are normal visitors, scheduled callbacks, forgotten download links, or something else. Request totals alone are not enough to decide when to stop it, especially if the old host also provides other services.

Check whether data remains split between the two sites, such as a final comment or form submitted to the old site. Once those records are saved and handled, prevent unnecessary new writes there. Do not overwrite the running new site with the old database; content added after cutover could be erased. Plan any merge by data type.

Use search reports to locate issues without jumping to conclusions

Search Console Performance reports show clicks and impressions by page, query, device, and date. Compare the same group of important pages first to distinguish a site-wide change from a decline in a few posts. If the domain changed too, inspect data for both properties rather than only the new site’s newly accumulating figures. Recent data may still be collecting, so a single hour is not a sound basis for a conclusion.

“Not indexed” in an indexing report does not always signal an error. Deleted pages, legitimate duplicate URLs, and intentionally private content can have valid reasons to be excluded. For an important URL that should be public, use URL Inspection to check its state, including whether a test noindex setting, wrong canonical, or broken redirect remains.

For example, if a popular craft tutorial suddenly loses traffic, open the old link and see whether it reaches the correct new article. Then check its text, images, and indexability. If the technical path is sound, examine the queries and comparison periods. These steps narrow the cause; timing alone does not prove that the host changed search rankings.

Give the new environment its own backups and owner

A pre-migration backup reflects one moment on the old host. Once the new site is active, it needs its own backup schedule, off-site storage, and restoration method. Create a new-environment backup manually first and confirm you can retrieve all the data, then check that the later schedule runs as intended. If backups still go to the old host, retiring it could also remove your recovery path.

Keep the necessary pre-migration copies, cutover logs, and configuration differences. Label filenames with the environment and time. Give each backup a purpose and retention owner rather than collecting archives no one can identify. Restrict access to copies containing personal data, and process them according to your internal retention policy when their period ends.

The person taking over should at least know the login entry point, incident contact, new backup location, and update window. Document who manages plugin licenses, form email, and scheduled jobs. A site may run correctly yet still lack a complete handoff if only the person who moved it knows those settings.

Decide service by service what can stop

Inventory hosting, email, DNS, domain, certificates, CDN, and redirects in the old account. Mark each item as “moved,” “still in use,” or “needs confirmation.” Changing hosts does not mean the domain should stop renewing. After a domain change, the old domain may still need to redirect links and receive mail, so the entire old account is not one expense to cancel.

There is no universal rule to delete the old site a fixed number of days after moving. First confirm that important features are stable, the old environment no longer handles required requests or data, the new backup works, and each dependent service has a destination. For unresolved items, assign a next review date and owner; that avoids both premature deletion and indefinite neglect.

Ask the provider what stopping renewal, deleting a website, deleting a plan, and requesting a refund each do. Under Hostinger’s official guidance checked for this article, turning off auto-renewal keeps service through the end of the term, while an eligible refund that is processed ends the service. These buttons are not interchangeable billing cleanup actions.

Finish the billing check and preserve closeout evidence

Before stopping a service, download any website files, database, and mail you still need. Make sure the only backup is not in the account about to expire. Hostinger’s site-deletion instructions also say to save data first and offer an option concerning associated email. Read each current screen during the operation rather than copying button locations or choices from an old tutorial.

After each action, save the service name, action date, confirmation, and last available date. A billing page saying auto-renewal is off is different from showing that this term is fully paid. Check what was paid and whether add-ons are billed separately. A website being unused does not mean every charge has ended.

End the closeout document with a short status: key functions pass on the new environment; old items that must remain and why; services already stopped; the new backup; and the maintenance owner. For outstanding work, state the next step and acceptance condition. The same record can guide a future host change, a new administrator, or a billing inquiry.

Move hosts while keeping the same URL

Hand off search and mail when changing domains

Back up the new environment

• Tutorials
• Apps & software
• Websites & e-commerce
• WordPress