Don’t Lose the Keys: What to Do When You Take Over a Website

A website is a working part of your organisation.

A good website is not just something you launch and admire, it is a working part of the organisation.

It helps people find you, understand you, trust you and take action. It may carry enquiries, bookings, donations, referrals, job applications, event registrations, campaign traffic or important service information.

So when a website is handed over by a developer, or when the person who manages it leaves, the organisation needs more than a cheery “we’ve got the login”.

You need to know who owns the account, who controls the domain, how two-factor authentication works, where form enquiries go, what renews when, who receives alerts, and what happens if something breaks.

None of this needs to be complicated. It does need to be known.

This is not about turning everyone into a web developer. It is about making sure your organisation can access, manage, protect and improve its own website without panic.

The parable of the enthusiastic takeover

Let us imagine a small organisation. We shall call it Helpful Hedgehog.

Helpful Hedgehog has a perfectly decent website. Their marketing manager has looked after it for years. He knows the login. He knows the platform. He knows where the domain is registered. He knows which email address gets the website alerts.

Then he leaves.

A colleague, full of energy and good intentions, says: “Don’t worry, I’ll take charge of the website.”

This is a good instinct. Organisations need people who step forward but unfortunately, Helpful Hedgehog has not done the dull but essential handover work.

The new website lead tries to log in. The platform asks for two-factor authentication but the code has been sent to the former marketing manager’s phone.

That phone is no longer available.

They try password reset. The reset email goes to an inbox nobody monitors.

They try to change the email address on the account. They cannot, because they are not fully authenticated.

They contact the website platform. The platform quite reasonably asks them to prove ownership.

They contact the former marketing manager who can't help because he is no longer an admin.

The evidence is scattered. The domain was registered by an old developer. The payment card belongs to a former trustee. The recovery email is a shared mailbox that was deleted during a Microsoft 365 tidy-up.

The website is still live, but nobody can safely manage it. A small update becomes a governance issue. A broken form becomes a service problem. A simple campaign becomes a delay.

Nobody meant to create a mess. They simply failed to treat website access as an organisational asset.

That is the lesson.

When taking over a website from a developer

If a developer has built your website and is handing it over to your organisation, do not just ask, “Can we edit the pages?”

Ask, “Do we understand and control the whole website estate?” That includes the website itself, but also the domain, hosting, email routing, analytics, forms, security, backups, integrations and payments.

Before the handover is complete, make sure you have the following:

1. Administrator access, not just editor access

There is a big difference between being able to change a paragraph and being able to manage the website properly.

You need to know:

• who has full administrator access;

• who has limited editing access;

• which account is the primary owner;

• what email address controls the main account;

• whether any access still belongs to the developer.

Where possible, the primary owner should be an organisational email address, not an individual’s personal email.

Use something durable, such as: website@yourorganisation.orgadmin@yourorganisation.or ; gdigital@yourorganisation.org

Not: bob1974@gmail.comformer.manager@oldemail.comthedeveloper@hotmail.co.uk

That may sound obvious. It is surprisingly common.

2. Two-factor authentication that the organisation can actually satisfy

Two-factor authentication, often called 2FA, is essential. It protects your website from unauthorised access. But badly managed 2FA can also lock the rightful organisation out of its own website.

Check:

• which phone number or app receives authentication codes;

• whether backup codes exist;

• where those backup codes are stored;

• whether more than one trusted person can access the account;

• what happens if the main account holder leaves.

Do not rely on one person’s personal mobile phone. You need security, but you also need continuity.

3. Domain name control

Your domain name is the address of your website. Losing control of it can be far more serious than losing access to a page editor.

You need to know:

• where the domain is registered;

• who owns the registrar account;

• when the domain renews;

• which payment method is attached;

• who receives renewal reminders;

• whether auto-renewal is turned on;

• where the DNS settings are managed.

DNS settings are the signposts that tell the internet where to find your website, email and other services. They are not glamorous. They are important. Do not change them casually. Do not let them sit in an unknown account either.

4. Hosting and platform details

Your website may be on Wix, Squarespace, WordPress, Shopify, Webflow or another platform. It may also have separate hosting.

You should record:

• platform name;

• account owner;

• plan level;

• renewal date;

• payment method;

• login URL;

• support contact route;

• what happens if the subscription lapses.

A website can disappear not because it has been attacked, but because a card expired and nobody saw the warning email because it was sent to the person who built the website.

That is not a cyber incident. That is admin coming back with a clipboard.

5. Email forms and notifications

Many websites have contact forms, booking forms, newsletter sign-ups or enquiry forms.

Check where those messages go.

Ask:

• which email address receives form submissions;

• whether submissions are also stored in the website dashboard;

• whether there is spam protection;

• whether any automated reply is sent;

• whether the form still works;

• who checks it;

• how quickly enquiries are handled.

This is especially important for charities, CICs and service organisations.

If someone asks for help through your website and the message goes nowhere, that is not just a technical problem. It is a service failure.

6. Analytics and tracking

You should know how the website is performing.

At a basic level, check:

• Google Analytics;

• Google Search Console;

• any platform analytics;

• Meta Pixel or advertising tags;

• cookie banner settings;

• who has access to each account.

You do not need to drown in data. You do need to know whether people are visiting, what they are looking at, where they come from and whether important pages are working.

Analytics should belong to the organisation, not to a developer’s general account.

7. Backups and recovery

Ask the developer or outgoing manager:

• is the site backed up;

• how often;

• where backups are stored;

• how quickly the site can be restored;

• what is included in the backup;

• what is not included.

If the site is on a managed platform, backup options may be limited or handled differently. Understand the reality.

A backup you cannot access is not a recovery plan. It is a comforting rumour.

8. Plugins, apps and integrations

Websites often rely on add-ons.

These might include:

• booking tools;

• donation tools;

• payment processors;

• newsletter systems;

• CRM forms;

• event calendars;

• accessibility tools;

• maps;

• review widgets;

• social media feeds.

List them.

For each one, record:

• what it does;

• who owns the account;

• whether it is free or paid;

• renewal costs;

• login details;

• data protection implications;

• what breaks if it is removed.

This avoids the classic moment where someone says, “I’m sure we don’t need that app,” followed by the donation button vanishing.

9. Content ownership and assets

Make sure you know where the original assets are.

That includes:

• logo files;

• brand colours;

• fonts;

• photos;

• videos;

• copy;

• downloadable documents;

• case studies;

• policies;

• terms and privacy notices.

You should also check whether images are properly licensed and whether consent exists for photos of people, especially service users, young people, volunteers or staff.

A website handover should not leave you guessing whether you are allowed to use your own homepage photograph.

10. Legal and compliance basics

Your website should include the right basic information.

Review:

• privacy policy;

• cookie notice;

• company or charity details;

• contact details;

• accessibility statement if appropriate;

• terms of use if needed;

• fundraising or donation wording if relevant;

• safeguarding signposting if relevant.

This is not about making the website sound like a legal textbook. It is about making sure the organisation is not exposed by old, missing or misleading information.

11. A simple website register

Create a simple website register.

It does not need to be fancy. A secure spreadsheet or document is enough, provided it is stored safely and access is controlled.

Include:

• platform;

• domain registrar;

• key accounts;

• account owners;

• renewal dates;

• payment methods;

• 2FA arrangements;

• backup arrangements;

• key integrations;

• named internal responsibility;

• external support contact;

• review date.

This is boring. Boring is good.

Being boring is how organisations avoid preventable chaos.

When your website manager leaves

The same principles apply when an internal website manager, marketing manager, communications officer or administrator leaves.

Do not wait until their final afternoon, when everyone is eating cake. Don't wait until a random day during what is their notice period but they are taking as holiday owed.

Have a proper digital handover.

And, while we are being practical, do not fall out with your website manager, at least not until the handover has been completed.

That may sound flippant, but it matters. The person leaving may still know where the digital keys are kept. They may know which email address controls the account, which phone number receives the 2FA code, where the domain is registered, which form sends enquiries to which inbox, and which button absolutely should not be pressed.

This does not mean one person should be allowed to hold the organisation hostage. It means the organisation should be calm, professional and methodical before it starts removing access, changing passwords or declaring that everything is now under control.

There is also a reputational point.

Looking locked out of your own website is not a good look.

Neither is being unable to update a staff page, fix a contact form, change an event date or respond to a basic platform security check.

For charities, CICs, social enterprises and public-facing organisations, that can damage confidence. Funders, partners, service users and customers may never see the access problem behind the scenes. They simply see an organisation that looks confused, out of date or slow to respond.

So treat the departure of a website manager as a business continuity issue, not a minor admin nuisance.

1. Change access before the person leaves

Before their final day, make sure:

• another person has full administrator access;

• recovery email addresses are current;

• 2FA is transferred or duplicated safely;

• backup codes are stored securely;

• passwords are changed where necessary;

• personal email addresses are removed;

• the leaving person’s access is reduced or removed at the right time.

This is not about mistrust. It is about good governance.

Even the loveliest former employee should not remain the accidental gatekeeper of your website.

But the order matters.

Do not remove the outgoing website manager until the new administrator has logged in, satisfied 2FA, received recovery messages and proved they can manage the account.

Removing someone before you understand the access chain can be the digital equivalent of changing the locks, posting the keys through the letterbox, and then remembering you are standing outside.

2. Ask for a guided walkthrough

Do not just ask for the password. Ask the outgoing person to show you:

• how to edit pages;

• how to publish updates;

• how to manage forms;

• how to check enquiries;

• how to update blogs or news;

• how to check analytics;

• how to restore or roll back changes if available;

• what not to touch without help.

Record the walkthrough if appropriate. At minimum, take notes.

The sentence “It’s quite easy once you’re in there” has caused a lot of trouble over the years.

3. Identify regular tasks

Ask what they do weekly, monthly and occasionally.

Examples might include:

• posting blogs;

• updating opening hours;

• checking broken links;

• responding to form enquiries;

• refreshing staff pages;

• adding events;

• updating policies;

• checking analytics;

• reviewing search performance;

• renewing plugins;

• updating WordPress components if relevant.

If nobody knows the routine, the routine will stop.

4. Check live campaigns

Before the person leaves, check whether the website is connected to any live activity.

This might include:

• paid advertising;

• fundraising campaigns;

• recruitment;

• event booking;

• grant reporting;

• service referrals;

• consultation forms;

• downloadable resources;

• social media campaigns.

A website is rarely just a website. It is often the landing place for everything else.

5. Remove access carefully

When the person has left, remove access from:

• website platform;

• domain registrar;

• hosting;

• Google Analytics;

• Google Search Console;

• email marketing platform;

• CRM;

• booking tools;

• social media accounts;

• advertising accounts;

• image libraries;

• shared drives.

Do it calmly and methodically.

Do not lock yourself out while trying to lock someone else out.

6. Review the website after handover

Once the handover is done, review the website properly.

Check:

• are the main pages accurate;

• are staff names current;

• are contact details right;

• do forms work;

• do buttons go where they should;

• are old events still being promoted;

• are policies up to date;

• are there broken links;

• is the site still aligned with the organisation’s current work.

A change of website manager is a good moment to tidy the cupboards.

The real risk is not technical

The problem is usually not that nobody in the organisation can code.

Most organisations do not need a web developer sitting in the office, waiting for something to break.

The real problem is much more ordinary: nobody is quite sure who owns the account, where the login details are, when the domain renews, who gets the form enquiries, which email address controls the website, or how the two-factor authentication is supposed to work.

That is not really a technical problem.

It is a management problem.

And, like most management problems, it is much easier to sort out before everything is on the floor.

A simple rule

Treat your website like an organisational asset, not one person’s personal project.

That means:

• access is documented;

• ownership is clear;

• 2FA is secure and manageable;

• renewals are tracked;

• forms are tested;

• analytics are accessible;

• responsibilities are named;

• handovers are planned.

And when someone leaves, keep it professional until the handover is complete.

You do not need a dramatic farewell, a digital tug of war or a sudden display of authority. You need working access, current recovery details, clear ownership and a calm transfer of responsibility.

Your website is often the first place people go to understand whether you are credible, active, trustworthy and useful.

It deserves more than “ask Jane, she knows the login.”

And when Jane leaves, as Janes sometimes do, your organisation should be able to smile, wish her well and carry on without a digital treasure hunt. Preferably without looking foolish in public or blaming Jane for your own mistake.

How Octopus3 can help

Octopus3 helps organisations make sense of the practical stuff behind websites, communications and campaigns.

We do not just make things look tidy from the outside. We help organisations understand what they have, what is working, what is risky and what needs to happen next.

That might mean reviewing your website access, helping with a developer handover, checking forms and analytics, planning content, sorting a landing page or making sure the website is doing the job it is supposed to do.

Because a good website is not just built. It is managed, reviewed and improved.

IF YOU WOULD LIKE TO GET A CHECKLIST TO HELP YOU THROUGH ONE OF THESE SITUATIONS, FOLLOW THIS LINK AND COMPLETE THE FORM - OR CALL +44 1539 312469 OR EMAIL enquiries@octopus3.co.uk