.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
You've built or migrated a site on a new server (maybe you just finished installing cPanel on a VPS and moved the files over) and the domain's DNS still points at the old one.
Now you need to see the site, and probably show it to a client, before flipping the records. cPanel's classic answer is the temporary URL, but that feature is half-dead on modern hosting and people burn hours discovering why.
Here's what still works in 2026, what doesn't and the two methods I rely on instead.
What the cPanel temporary URL is
The traditional temporary link uses Apache's mod_userdir module and looks like one of these:
http://SERVER_IP/~username/
http://server-hostname.example.net/~username/The tilde-username maps to your account's public_html, so the site renders without any DNS in place. Hosts each have their own flavor of the hostname version (InMotion, Namecheap and the rest print theirs in the welcome email), but it's all the same mechanism underneath.
Why your temporary URL doesn't work
On most shared and managed servers today, mod_userdir is switched off, and for defensible reasons. It leaks usernames, it lets one account's traffic ride another domain's reputation and on servers running PHP handlers like FPM per-account it often executes PHP in the wrong context or not at all. So the ~username link returns a 404 or the provider's default page, and the knowledge base article you followed turns out to be from 2016.
Even where the temporary URL works, two problems follow it around. CMS platforms with absolute URLs (WordPress above all) redirect straight back to the real domain or load a page with broken styles, because the site believes it lives at example.com, not at hostname/~user. And there's no SSL for the tilde path, so anything with a forced HTTPS redirect loops. My take: the temporary URL is fine for checking that a plain HTML page landed on the right server and not much beyond that.
If you run your own VPS with WHM, you can flip it on anyway: WHM » Security Center » Apache mod_userdir Tweak, untick the exclusion for the account you're testing, save. It's your server and your call. I leave it off and use the hosts file method below, which has none of the drawbacks.
The hosts file method (the reliable one)
Instead of asking the server for a special URL, you tell your own computer that the domain already points at the new server. The site loads under its real name, so WordPress, redirects and SSL all behave normally. Only your machine sees the new server; the rest of the world keeps getting the old one.
Windows
Open Notepad as administrator, then open:
C:\Windows\System32\drivers\etc\hostsAdd two lines at the bottom, using your new server's IP:
203.0.113.10 example.com
203.0.113.10 www.example.comSave, then flush the DNS cache from a command prompt:
ipconfig /flushdnsmacOS and Linux
sudo nano /etc/hostsAdd the same two lines, save with Ctrl+O and exit with Ctrl+X. On macOS, flush with sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder.
Load the domain in a private browsing window (regular windows love serving you a cached copy of the old site) and you're browsing the new server as if DNS had already moved. When testing's done, delete the lines or comment them out with a leading #. Forgetting a hosts entry is a classic footgun; a month later you're debugging why "the site looks different on my laptop" and it's your own edit.
One caveat: AutoSSL can't issue a certificate for a domain the world's DNS doesn't point at yet, so HTTPS shows the wrong or a self-signed certificate until after the real switch. Expected, ignorable during preview.
Share the site with a subdomain and a document root
The hosts trick covers you, but you can't email a client a hosts-file edit. What you can send them is a working link, and this is where the document root move comes in. The idea: take a domain that already resolves to this server (your agency domain, any parked domain you own) and hang a subdomain off it whose document root points at the new site's folder.
In cPanel » Domains » Create a New Domain, add something like:
preview.youragency.comand set its document root to the folder the client's site lives in, for example public_html/clientsite (untick "share document root" with the main domain so the field becomes editable). DNS for the subdomain resolves within minutes since the parent domain is already on this server, AutoSSL issues a certificate for it and you've got a clean HTTPS link anyone can open on any device. No hosts edits, no tilde URLs.
The WordPress caveat applies double here: the database still holds the final domain in its URLs, so either keep the preview to visual checks or do a temporary search-replace to the preview URL (WP-CLI's wp search-replace, then reverse it before launch). Building the site fresh on the new server instead of migrating it sidesteps the whole problem; the cPanel WordPress setup guide covers that route. Static sites and most custom PHP apps preview perfectly with zero changes.
Delete the subdomain once the client signs off. Preview URLs left alive become duplicate-content noise in search engines and occasionally end up indexed, which is an awkward email to receive.
Flip DNS and confirm
When the preview passes, update the domain's A record to the new server IP and drop the TTL beforehand if you can (300 seconds makes the cutover snappy). Propagation is uneven across resolvers; a DNS checker shows you when the major public resolvers worldwide have picked up the new record. Once they have, remove your hosts entries, run AutoSSL on the real domain and retire the preview subdomain.
Between the three approaches, my order of preference hasn't changed in years: hosts file for me, preview subdomain for the client, temporary URL almost never. This applies on any cPanel host; on your own cPanel VPS you additionally control the mod_userdir tweak and the DNS zone TTLs yourself, wich shaves the last waiting out of a migration.
