Behind Your Domain
PHP: Where a Site Keeps Its Own Domain Name
You changed the name, the delegation is correct, and the site still sends every visitor back to the old address.
The short answer
PHP is the server-side language most hosted sites are written in, and for a name-holder its relevance is narrow and sharp: PHP is what decides which address a site believes it lives at — either by reading the host header on every request, or by trusting a value that was written down once, at install time.
A site that reads the header follows whichever name you point at it. A site that trusts a stored value, and WordPress is the obvious example, goes on emitting the old address in its links, its canonical tags, its own redirects and its password-reset emails until the stored value is changed too.
Which is why a domain change is two jobs rather than one: the delegation, and the value inside the application.
By the Hosting & Domains team · Reviewed 18 August 2026
0
Terms left unexplained
100+
Entries, each cross-referenced
Real
Records, not hypotheticals
Free
To read, no account needed
The version matters for a second, related reason. PHP is set per site from the control panel here, and an application pinned to an ageing release is the usual thing blocking a rename, because the migration tool or the command-line utility you need refuses to run on it. Moving a site from 7.4 to 8.3 is a dropdown, and it is often step one of the rename rather than a separate errand for later.
Then there is the redirect a site performs on itself. A stored address still naming the old domain will bounce every visitor from the new name back to the old one, and once the old name has been retired the site becomes unreachable from either. So the stored value changes before the old name goes, never after — that ordering is the whole of the advice.
Two ways an application learns its own name
Reading it from the request means the application takes the name the visitor typed and builds every link from that. Point three names at such a site and all three appear to work, which is convenient and quietly produces three addresses serving identical pages. Trusting a stored value means the application ignores the request entirely and insists on the one address it was told about, which is stricter and much less forgiving of a rename.
Neither is wrong. Knowing which one you are dealing with, before you touch the delegation, is what separates a fifteen-minute rename from a lost afternoon.
The self-redirect that locks you out
The sequence goes like this. You point the new name at the account. The visitor asks for the new name. The application checks its stored address, sees the old one, and issues a redirect to it. If the old name still resolves, you get a confusing loop back to the address you were leaving. If it does not, you get nothing at all — and the admin screens, which you would use to fix the stored value, are behind the same redirect.
The recovery is to set the value outside the application: a constant in the configuration file, or a direct edit to the settings table. Which is a fine thing to know, and a better thing to never need.
Cookies, sessions and the dropped login
Cookies are scoped to the name that set them, so nothing issued at the old domain is sent to the new one. Every logged-in session ends at the moment of the rename, which is correct behaviour and still surprising: a shop's baskets empty, an editor is signed out, a membership area asks everybody to log in again.
Warn the people it affects and pick a quiet hour for the switch. There is nothing to fix here, only something to expect.
Where the old name goes on hiding
Beyond the settings row, the old address is written into the body text of pages as absolute links, into image sources, into menu items, into whatever an SEO plugin has stored as the canonical, into a scheduled task's callback URL, and into the From header the site puts on outbound mail. None of those move when the delegation moves.
The mail one costs the most and shows the least. Mail sent from an address at the new name is checked against the SPF record and DKIM signature published at that name, so a site that has been renamed but whose authentication records were left at the old name watches its confirmations land in junk folders while every page looks perfect.
Version, per site, from the panel. Because the version is set per site, a legacy application and a current one can run side by side in one account — which matters when you are consolidating several names onto a single plan and one of the sites is elderly. Extensions and per-site tuning are on the same screen, and none of it goes near a support ticket.
Read on: MySQL, WordPress, Database and Domain Name.
The rate you register at is the rate you renew at, so year two costs precisely what year one did.
Why a hundred domain terms were worth writing down
Jargon is what turns a five-minute change into a lost week. This is the domain desk's own reference, published where a search engine can hand it to you instead of us.
The rate you register at is the rate you renew at, so year two costs precisely what year one did.
- Plain English, from apex to zone file
- What the registry does, and when it does it
- The failure mode named in every entry
- Maintained by our own domain desk
Why Hosting & Domains
Standard on every plan
Written for name-holders
Not for sysadmins. The reader here owns the address and needs to keep control of it, which is a different problem from running the box.
Checkable, not merely readable
Where a claim can be verified with dig, whois or curl, the entry says which command to run and what a good answer looks like.
Mail treated as a first-class risk
Anything that can strand a mailbox is flagged where it comes up, rather than left to a separate article nobody reaches.
Renames, in the right order
Which value a site trusts, where the old name hides afterwards, and why the stored address changes before the delegation.
Ownership before configuration
Who holds the name comes first and how the site is set up comes second. That order is deliberate, and it is the order things break in.
One hundred entries, cross-referenced
The vocabulary of names, records and registries in one place, each entry linked to its nearest neighbours.
Quick Start
Order placed to site online
- 1
Check it from outside your own browser
A browser shows you a cached, redirected, sometimes HSTS-pinned version of reality. dig, whois and curl -I show the answer as it actually stands right now.
- 2
Change one thing, then confirm it
Delegation, server configuration and the site's stored address are three separate changes owned by three different systems. Verify each before you make the next.
- 3
Keep reading
MySQL, WordPress and Database are the neighbours here, and each takes about two minutes.
Built In
Fitted to every plan
- Auto-renewal switched off with a toggle in the account, with no phone call
- Mailboxes that answer at the name you hold
- Standalone email hosting for a name whose website lives elsewhere
- Free SSL on every plan, reissued before the old certificate lapses
- PHP version chosen per site from the control panel
- NVMe SSD storage on every tier, not only the expensive ones
- LiteSpeed caching built into the server rather than bolted on by a plugin
- WordPress and 400+ further applications installed in one click
- Softaculous included for one-click application installs
- WordPress Toolkit, with the updates seen to for you
Frequently Asked
Questions we field again and again
I changed my domain and the site redirects straight back to the old one. What is doing that?
The application, not DNS. It has the old address stored and is insisting on it. Change the stored value — in WordPress that is the site address and home settings — and the redirect stops. If the redirect is already blocking you out of the admin screens, set the value in the site's configuration file or directly in the settings table, then log back in and confirm it.
Does moving a site to a new domain need a code change?
Rarely a code change, usually a data change. Well-built applications read the name from the request or from one setting, and both are configuration. What does need attention is everything the old name was written into by hand or by import: absolute links in content, image sources, a stored canonical, a scheduled task's URL and the From address on outbound mail.
Which comes first, the DNS change or the site's stored name?
Add the new name to the hosting account first, so the server will answer for it. Change the site's stored address next. Move the delegation last, and keep the old name registered and pointing at the same account for a good while afterwards so the redirect you leave behind still works. The old name is retired last of all, never first.
Can one name run an old PHP version while another runs a current one?
Yes — the version is chosen per site from the control panel, so two names on the same account can sit on different releases. That is genuinely useful during a consolidation: the elderly site keeps working on the version it needs while the rest of the account moves forward, and you upgrade it when you are ready rather than when the move forces you to.
Keep reading
WordPress Hosting
WordPress looked after for you: LiteSpeed caching, staging copies and a daily backup.
Domain Names
Search, register and transfer names — year one free with annual hosting.
Changing provider? Work through this checklist beforehand.
A straightforward running order for a migration your visitors never spot: which files travel first, how to bring the mail across without dropping a single message, the right moment to repoint DNS, and the two errors that sit behind almost every outage we get called in to fix.
Hold the name, hold the site.
Free SSL, a free migration, the name's first year included on an annual order, and a person on the desk at any hour.
View Domain Names plans