How to tell whether you actually own your website

Paying for a website is not the same as owning one

One arrangement works like this. A business pays a monthly fee and receives a website. Somebody registered the domain, somebody built the pages, somebody set up the email, and the invoice arrives every month with a single line on it. From the outside that is indistinguishable from owning a website and paying somebody to look after it. It is not necessarily the same thing.

The distinction is not about quality. Many of these sites do the job they were built for. The distinction is about what remains yours when the arrangement ends. In a rented arrangement the domain may be registered to the provider, the content may exist only inside a platform with no export, the hosting is theirs by definition, and the addresses your customers write to are administered by the company you would be leaving. Cancelling returns nothing, because nothing was ever handed over.

This is not confined to packaged products sold as a monthly bundle. A local developer who registered a domain on their own account, in good faith, years ago produces the same position the day they retire or stop answering the phone. An arrangement does not have to be predatory to leave a business stuck.

None of it surfaces until the day you want to change something the provider will not change, or leave. At that point it decides whether your next website is a project or a rescue.

Six checks, and the order to do them in

Do these while you are still content with the arrangement. Each one is a reasonable question for a paying customer to ask, and asking it before you have mentioned leaving keeps it a question rather than a negotiation.

The first two decide how serious the others are. If the domain is registered to your business at a registrar you can log in to, and you can change where it points, everything else is recoverable work. If it is not, that is the thing to solve first, because the rest depends on it.

• Who the registrant is. Look the domain up on a public WHOIS service and read the registrant line — the legal holder, not the administrative contact and not the registrar's own trading name. Redaction rules differ by registry, so a withheld answer proves nothing in either direction. The check that does prove something is whether you can log in to an account, in your business's name, at a registrar, and see the domain sitting in it. While you are in there, note the expiry date, whether auto-renew is switched on, and whose card it is billed to. A domain that lapses is a harder problem than a domain in the wrong name.
• Who publishes the DNS. A domain can be registered to you and still be delegated to nameservers you have no access to, and whoever holds that zone decides where the website resolves and where mail is routed. That control is real, but it is not superior to the registration: from the registrar account you can re-delegate the domain to nameservers of your choosing, which overrides the existing zone. So establish two separate things — which nameservers the domain currently uses, and whether you can change them. A public DNS lookup tool answers the first. Only the registrar account answers the second.
• Whether the content can leave, and whether you can have it now. Ask for a database export and the site files, in those words, and ask for a copy today rather than an undertaking about what happens if you ever leave. A request for "a copy of my website" can be honoured with a folder of scraped pages that will not import into anything, and nobody has technically lied to you. If the site runs on a proprietary builder with no export, that is your answer, and the content will have to be rebuilt rather than moved.
• Where mail actually routes. Look up the domain's MX records — the same public DNS lookup tools do this, and there are checkers built specifically for mail records. The MX records name the service that receives mail for your domain, which tells you whether that is a mailbox provider you hold an account with or your website provider's own infrastructure. Then establish who administers the mailboxes, who can reset a password, and whether anybody other than the provider can create a new address.
• Where your reviews and listings live. Reviews on a Google Business Profile belong to the profile rather than to the website, so moving the site does not disturb them. The separate question is whether you can still administer the profile after leaving. Open the profile's people-and-access settings, where every account with access is listed as Owner or Manager, and confirm an account you control is an owner rather than a manager somebody added — or that you are on it at all. Reviews collected inside a provider's own directory product stay with that product.
• What the contract says you own. Who holds the copyright in the copy, the photography and the logo, and whether any of it is licensed to the provider rather than assigned to you. Stock images bought under a provider's licence do not necessarily come with you, and a logo drawn under a contract that never assigned it is still theirs. This is a reading exercise rather than a technical one. Do it in the same sitting as the others.

Why mail is the part with the least tolerance

A move gets planned around the website, because the website is the visible part. Mail is the component that can be broken without anybody noticing, for three reasons that compound each other.

The first is entanglement. Where the mailboxes were set up as part of a website package, they sit on the same infrastructure and under the same account, so cancelling the website can cancel them.

The second is that mail routing lives in DNS, and it is easy to move it without meaning to — though not in the way people expect. Repointing a domain at a new website changes the A or AAAA record, or a CNAME. It does not touch the MX records, and on its own it does not move mail anywhere. What moves mail is changing the domain's nameservers, because delegation hands the entire zone to a new provider: if the new zone does not reproduce the existing MX records exactly, along with the SPF, DKIM and DMARC records that authorise your senders, mail stops arriving where it was arriving. A hosting control panel can produce a similar result from the other direction, by treating a newly added domain as one it handles mail for locally — after which anything the server itself sends to an address at that domain, a contact form notification included, is delivered into a mailbox on the server rather than to your real mailbox provider. The precaution that covers both is the same: record the whole existing zone before delegating anything, and reproduce it deliberately rather than assuming a new provider will infer it.

The third is that mail fails silently. A broken website announces itself. A domain whose mail is being rejected at the far end, or filed as spam there, produces no signal at all on your side — there is nothing to notice, so the gap between the change and the discovery is decided by whoever eventually rings to ask why nobody replied.

There is also the archive to think about, separately from the flow. The mail already sitting in those mailboxes may be the only record of what was quoted, agreed, amended and confirmed with a customer, and it does not reconstruct itself from anywhere else. Moving live mail routing and moving mail history are two different pieces of work, and only one of them has to happen on the day.

What carries across a move, and what does not

Nobody can promise you that rankings are preserved, and anybody who does is guessing. What can be described is the mechanism, and the mechanism is what tells you which decisions affect the outcome.

A search engine associates a specific address with specific content. What it has learned about a page, including which other sites link to it, is attached to that address rather than to the design or the platform. Move the content to a new address and say nothing, and the association has nowhere to go. Move it and leave a permanent redirect from the old address to a page covering the same subject, and there is a path for the association to follow.

That is the principle. It does not settle the execution, and the execution is where a move comes apart, because the conditions below have to hold together rather than individually.

• Whether the domain changes at all. A move that keeps the domain is a change of address within the same building. A move to a new domain relies entirely on the redirects to carry the association across, and therefore on the old domain staying under your control long enough to serve them.
• Whether every old URL is mapped one-to-one to a genuine equivalent. Redirecting the whole of an old site to the new homepage is technically a redirect and practically a discard.
• Whether the redirect map was built from a real inventory of the old URLs rather than from the new site's menu. A crawl of the live site and a list of pages showing in analytics will both miss the addresses that matter — a page nothing links to internally, or a page with inbound links from elsewhere and no traffic of its own. Fill the gaps from Search Console's list of indexed pages, the existing sitemap file, and the server access logs, which record requests for addresses no crawl will ever reach.
• Whether the content survives the move recognisably. A page redirected to something covering an entirely different subject is not an equivalent and will not be treated as one.
• Whether the new site is crawlable and indexable on the day it goes live. One failure worth checking for specifically is a staging setting left switched on, which tells every search engine to ignore the site it has just been redirected to.

One further decision has nothing to do with technique. Change platform and rewrite all the content in the same week, and if something moves afterwards you have no way of telling which of the two caused it. There is a real argument for moving first with the content as it stands, letting things settle, and improving the content as a separate exercise. It is less satisfying and it is much easier to diagnose.

As for what does not come with you: anything that only ever existed inside the old provider's product. Their directory listing, their review widget, their traffic reporting, and form submissions where the data sits on their servers. Export what can be exported before you give notice, and treat the rest as gone.

The order matters more than the tools

"Just move it" fails because the components depend on one another in one direction only. DNS is the last domino, and nearly everything else has to be standing before it falls. The reasoning behind each step is more use to you than the step itself, because it tells you what somebody doing this properly is spending your week on.

• Run the ownership checks before giving notice to anybody. What they turn up decides whether this is a migration or a recovery, and those are different projects.
• Get the domain into an account you control, at a registrar you control. Everything downstream hangs off it, and it is the one where you are waiting on somebody else rather than on yourself.
• Take a full copy while the old site is still live and cooperative: files, database, images, product data, and a written list of every URL that currently exists.
• Build and test the new site on a temporary address, with its URL structure decided against that list of old URLs rather than invented first and reconciled afterwards.
• Plan the mail as a separate exercise with its own checks: new mailboxes standing and tested, historical mail moved, and every record that authorises a sender for the domain reviewed, before anything touches the live MX records.
• Lower the DNS time-to-live on the records you are about to change, and then wait before changing them. A resolver that cached a record before you lowered the TTL keeps the old value for the remainder of the old TTL and does not see the new, shorter one until then. So the reduction only takes effect after the previous TTL has run its course, and it has to be made at least that far ahead of the cutover. Lower it shortly before the switch and the change propagates at the old speed anyway, with some visitors landing on the old site and some on the new one throughout.
• Write and test the redirect map against the real URL list, then switch DNS. Keep the old environment running and paid for until nothing is pointing at it.
• After the switch: confirm the new site is indexable, submit the new structure for crawling, send and receive mail in both directions including to an external address on a mainstream provider, test every form, and watch the server logs for requests to old URLs that nothing is catching.

The last step is the one worth protecting when time is short. A migration is not finished at the switch. It is finished when the logs are quiet.

When a check comes back badly

The remedy depends on which check failed, and the answers are not equally good. Work out which of them you are facing before you give notice rather than after.

If the domain is registered to your business but sits at a registrar your provider manages, the domain is transferable and the obstacle is administrative. For a .com, .net or similar, a transfer to another registrar needs three things from the one you are leaving: the domain unlocked, an authorisation code issued to you, and the registrant contact address in a state where you can actually receive the confirmation message. The code is issued by the losing registrar and it expires, so request it once the receiving registrar is ready rather than collecting it in advance. Transfers are also blocked for a set period after a domain is first registered and after a previous transfer between registrars, and at some registrars after a change to the registrant details. That lock is policy rather than your provider's decision, and the registrar can tell you the date it lifts.

For a .uk domain the mechanism is different, which is worth knowing before you ask for the wrong thing. There is no authorisation code. The record carries a registrar tag identifying who manages it, and moving the domain means having that tag changed to the new registrar's. Nominet is the registry that holds the record, and the tag change is requested through the registrar currently on it.

If the provider is named as the registrant rather than you, this is not a transfer problem at all. Changing who the registrant is, is a different process from changing which registrar holds the domain, and it needs either the current registrant's cooperation or a contractual basis to require it — so the agreement is the first thing to read, not the registrar's help pages. Where a gTLD registrar is not meeting its own transfer obligations, ICANN accredits it and publishes a complaints route. Where the domain is .uk, Nominet publishes what it requires in order to correct a registrant record. Neither is an instant remedy, and that is the argument for running these checks at a moment of your choosing.

If the domain cannot be recovered, the fallback is a new domain, and the plain version of what that costs is this. You cannot redirect from an address you do not control, so the links, the bookmarks and the search associations attached to the old domain stay attached to it. What you can do is build on a domain that is yours from the first day, tell customers and suppliers the address has changed, update every listing, profile and directory entry that names the old one, and treat the search side as a fresh start rather than a continuation.

The other two failures are less severe than they look. If the content will not export, the content has to be rewritten and rephotographed — but the URL list still matters, because addresses can be preserved even when the pages behind them are new. And if the entanglement is the mail, mail can be moved to a provider of your own before the website goes anywhere at all, provided you can change the domain's DNS records. That is the second check again, and it is why it comes second.

When there is nothing here to fix

The checks can also come back clean. The domain is registered to the business, at a registrar you can log in to. The nameservers are yours to change. The site runs on a mainstream platform you could export tomorrow. The mail is with a provider you pay directly and administer yourself. If that is your position, you do not have an ownership problem, and moving would not fix anything, because nothing is being held.

The question left is whether the website does its job, which is a different assessment and a better one to be having. Three things are worth testing, and none of them requires moving anything.

• Whether people can find it. Search for the business by name and confirm your own site is what a person sees first. Then search the phrases a customer would use for the thing you sell, with no business name in them, and note what comes back instead. Then check the site is verified in Search Console and read what it reports as indexed: a page missing from that list cannot rank, whatever else is true of it.
• Whether people understand it. Show the homepage to somebody outside the business, give them no preamble, and ask them what the company does, who it is for, and what they would do next. Where they hesitate is the copy to rewrite.
• Whether enquiries reach you. Send a test enquiry through every form on the site from an external address on a mainstream mail provider, and confirm it arrives in an inbox rather than a spam folder. Then reply to it from the address the business actually sends from, and confirm that arrives too. A form can report success on screen and deliver nothing.

Between the two extremes is the partial position: the domain is yours but the content is stuck, or the site is portable but the mail is entangled. That is the reason to run the checks as a set rather than stopping at the first reassuring answer. They do not have to agree with each other, and knowing which pieces you already hold is what decides how much of this has to be negotiated and how much does not.