What should I check on a website I have just inherited?

The registrar, and whose account the registration sits in. A domain registered by a previous agency under its own account is the most common inheritance problem and the hardest to fix late.

The expiry date, and whether renewal is automatic and charged to a card that still exists.

The nameservers, which tell you which provider actually answers for the domain — frequently not the one anybody remembers.

Whether DNSSEC is enabled, since moving DNS providers with it enabled requires a careful sequence rather than a simple switch.

Nothing else on this list can be changed safely until these four are known.

Mail: the mail exchanger records say where mail for the domain is delivered, and that service has an account somebody owns.

Mail authentication: the sender policy lists every service allowed to send as the domain, which is an inventory of third parties in one record.

Subdomains pointing at services — a help desk, a status page, a shop — each with its own account and its own renewal.

Verification records left by services that were tried once and abandoned, which are harmless individually and a map of history collectively.

A record pointing at a service that no longer exists is worth removing early, since a dangling name can be claimed by someone else on some platforms.

The hosting provider and the network it sits on, which the IP addresses and the autonomous system reveal even when nobody wrote it down.

Whether a CDN or a reverse proxy sits in front, which decides where caching, certificates and firewall rules are configured.

The deployment provider, if one is detectable, which is where the build and the environment variables live.

Whether the origin server is reachable directly, bypassing the proxy — which matters if the proxy is where protection was configured.

The platform and its version: a content management system two major versions behind is a maintenance debt you now own.

Files served publicly that belong to development: source maps, environment files, repository metadata, backup archives.

Credentials in the shipped front-end code, which the previous team may not have known were there.

Secondary environments — a staging copy, an old version — still reachable on a subdomain and possibly indexed.

Administration and login surfaces on predictable paths.

Each of these is a finding that was true before you arrived and is your responsibility from now.

Analytics, advertising and session-recording scripts, each of which is a data processor you are now answerable for.

Trackers that load before any consent, which is a compliance question inherited along with the code.

The same tag loaded twice, which is common after several teams have each added their own.

Embedded content from other domains, which sets its own cookies on your visitors.

An inventory is the prerequisite for any decision here, since removing a script nobody can explain is safer once you know what it does.

Who holds the passwords. Account access is only answerable by the people handing over.

Whether backups exist and whether anyone has ever restored one.

Which contracts, licences and renewals are attached to the services you found.

Why a given configuration exists — some odd choices are deliberate, and the reason is in someone's head.

So the external inventory is the agenda for the handover conversation rather than a replacement for it.