Website Handover Checklist, What Should Be in Your Name at Launch

A website handover checklist is the list of accounts, logins and files which should be in your name on the day the site goes live, and I think it’s really six things, the domain, the hosting and its backups, your own administrator login, every paid licence the site uses, the design files, and the Google accounts which measure the site. Most of them cost nothing to sort out at the end of a project and a lot to recover a year later, which I see whenever I look after a site after its launch, such as a shop where the membership behind two premium plugins had expired more than two months earlier, so the security fixes for both plugins could not be installed until the licence was renewed.

This post goes through each item in the order which I would check it, with what you should hold and how to confirm that you hold it.

The domain

The domain is the one item which is hardest to win back, so I would check it first. ICANN, which oversees domain names, calls the person or company that holds the rights to a name the registrant, and its registrant FAQ points out that a developer who registers a name with their own details may be the registrant of record even when the client paid for it, in which case the client may need the receipts to prove otherwise.

So I would log in to the registrar’s dashboard, the company where the domain was bought, and check that the account is yours and that your name or your company’s name is the registrant. ICANN’s guidance on accurate registration data asks the registrant to update their details within seven days of a change, and its current Transfer Policy lets a registrar lock the domain against moving to another registrar for 60 days after the registrant changes, so if you plan to move the domain as well, it’s worth asking for that move before the change of name.

The hosting and the backups

The hosting account should be in your name too, or at least shared with you so that you can log in without the developer, and I would ask where the backups are kept, how often they run and how a restore works. In my monthly round of updates across eleven sites, most hosts took a daily backup, one site ran on a host with no backup that I knew of, and one site did not appear in the hosting account which I had been given at all, so it stayed out of that round.

Your own WordPress login

You should have your own user with the Administrator role, which WordPress’s roles and capabilities guide describes as the role with access to every administration feature on a single site, and on a single site only an Administrator can install and update plugins, themes and WordPress itself. The developer should then have a separate user of their own, which you can remove or downgrade from the Users screen with Change role to, rather than one shared login that everybody uses.

Tools which publish to the site, such as a script or an app, should use an application password, which WordPress has offered since version 5.6, which you can revoke one at a time on the user’s profile, and which cannot be used to log in to wp-admin. This website publishes its posts that way, so I can switch off one tool without changing my own password.

Before the handover I would also take a copy of the content through Tools, then Export, which downloads a WordPress eXtended RSS file with the posts, pages, comments, custom fields, categories, tags and users, as the Export screen guide lists, and since that file holds the content, a full copy of the site with its theme, plugins and database still comes from the host’s backup.

Every paid licence

Paid plugins and themes mostly update through their makers’ own servers, and the update only arrives while the licence is active, so each licence should sit in an account which you can log in to, with a renewal date in your calendar and a card which you know about. The shop site above shows what happens otherwise, and on another site in my October round a premium menu plugin answered “Download failed. Unauthorized” because its licence key was missing, which I wrote about in my post on how to update WordPress plugins safely.

I would ask for a written list of every paid plugin, theme and outside service with the account it is in, the price and the renewal date, which is one of the questions to ask a web designer before the project starts as well.

The design files

The Figma file holds every page at desktop and phone size, the colours, the type and the components, and it’s the file which the next designer or developer will want before they change anything. In Figma only the owner can hand a file over, through Share, then the person’s permission, then Owner and Transfer ownership, which Figma’s guide to transferring ownership says cannot be undone and does not move the file, and outside drafts the new owner has to be a collaborator on the file already. Moving a file into your own team is a separate step, which Figma’s guide to moving a file says needs can edit access in both teams.

If you only want to look at the file, can view access is enough, and Figma’s permissions guide notes that view seats are free.

Search Console, Analytics and Tag Manager

The Google accounts which measure the site should list you as the owner or the administrator, and the developer as a user whom you can remove. In Search Console, Google’s guide to owners, users and permissions separates a verified owner, who proved ownership with a token, from a delegated owner and from full and restricted users, and it advises removing previous owners’ verification tokens when you take a site over. In Google Analytics the role to hold is Administrator, and in Tag Manager it is Admin on the account with Publish on the container.

Where to start

I would open a note today with the six rows of the table above, then log in to each account in turn and write down whose name it is in, and any row where you cannot log in or where someone else is the owner is the one to raise with your developer this week, starting with the domain. If the project is still under way, it’s easier to agree the list now and receive each login as the account is made, so the handover on launch day is a check of the list and not a search for passwords. If you are about to choose someone for a new build, my post on freelance or agency web design covers the other side of that decision, and my about page shows how I work.

Frequently asked questions

What should be included in a website handover?

The domain in your name, the hosting with backups, your own administrator login, every paid licence with its renewal date, the design files, and owner or administrator access to Search Console, Analytics and Tag Manager, plus a written list of each one.

Who owns my domain if my web designer bought it?

The registrant listed at the registrar holds the rights to the name, so if the designer registered it with their own details, ask them to change the registrant to you, and keep the receipts for the domain in case you need to show that you paid for it.

Should my developer keep an admin login after launch?

Only while they still work on the site, on a user of their own, and I would downgrade or remove that user once the work ends, along with any application passwords which their tools used.

What is a website handover document?

It is the written list which goes with the site, with each account, whose name it is in, what it costs and when it renews, plus how to restore a backup and who to call, and I would keep it somewhere outside the website itself.

Do I need the Figma file after the website is live?

Yes, I think so, since the next change to the site starts from it, and a designer who receives the file can reuse the existing colours, type and components rather than measuring the live site to redraw them.