You have been handed a website and no documentation. Before changing anything, find out what you are actually holding, because a change made without knowing where the DNS lives can take the site and the email down at once.
Four questions, answerable without any credentials
whois example.com | grep -iE 'registrar|expir|name server' dig example.com NS +short dig example.com A +short dig example.com MX +short
Where the domain is registered, and when it expires. The expiry date is the most urgent item on this page: a domain expiring next month while nobody has access to the registrar is a genuine emergency.
Where the DNS is hosted. Frequently not the registrar and not the hosting company. A service added years ago for one feature and never revisited.
Where the site is served from. Compare it against whatever hosting account you were given. If they do not match, the account you were handed is not serving the live site.
Where mail goes. Often somewhere nobody mentioned.
Using dig and nslookup goes over reading the answers.
Get registrar access before anything else
Hosting can be replaced. A domain you cannot reach cannot.
The registrant contact recorded on the domain is what decides who can recover it. If that is your client's name, the registrar has a process. If it is a former developer's, that is a conversation to start immediately rather than after a problem. Moving a domain between registrar accounts walks through the routes.
While you are there, confirm the contact address reaches somebody, because an unverified one suspends the domain fifteen days later. Unverified contact details sets out that failure.
Then the hosting account
Log in and look at what is actually there before assuming the site is what you were told.
How many domains and subdomains the account serves. What is in the web root, frequently an old site, a staging copy and the live site all together. How many databases exist and which the site uses. What email accounts exist and whether anyone reads them.
Also read the FTP account list. Departed developers' accounts are usually still there and still working. Managing FTP accounts walks through clearing them, and this is one of the first things worth doing.
Find out what the site is built on
curl -sI https://example.com | grep -iE 'server|x-powered' ls ~/public_html | head -20
A wp-config.php means WordPress; a vendor directory suggests a framework; plain HTML files mean a static site.
For WordPress specifically, the plugin list and the last-updated dates tell you most of what you need. For that in detail, see auditing a WordPress site you inherited.
Take a backup before you touch it
Whatever state the site is in, that state currently works. Capture it (files and database) and keep the copy somewhere other than the account.
This is the point at which most inherited-site problems become recoverable rather than permanent. There is more on what a good backup needs to contain in restoring a website.
Check the things that expire
The domain. The certificate. The hosting plan itself. And any third-party service the site depends on. A form provider, a mailing service, an API key.
echo | openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -enddate
Anything that renews automatically is renewing against a payment method somebody set up, which may belong to a person who has left. Managing a portfolio of domains goes into keeping track.
Write the document that did not exist
Registrar, DNS provider, host, plan, what the site is built on, which services it depends on, who holds each credential, and what expires when.
One page. It is the thing whose absence created this situation, and writing it is the difference between handing this on well and passing on the same problem.
The yearly maintenance checklist goes into keeping it current.
Find out who is paying for what
The technical inventory has a financial half that is easier to obtain early and awkward later.
Which card or account pays for the hosting, the domain and any third-party service. When each renews. Whether any of it is on a personal card belonging to somebody who has left.
That last case is common and produces a specific failure: a service lapses because the card was cancelled, and nobody connects the outage to a person who left months earlier. Reading your hosting invoice sets out what renews independently.
Check whether anything is scheduled
An inherited site frequently has jobs running that nobody mentioned. A nightly export, a feed import, a backup writing somewhere.
crontab -l ls -la ~/logs/ | head wp cron event list --fields=hook,next_run_relative 2>/dev/null | head -20
Two things matter here. A job that is failing silently has been failing for as long as nobody was watching. And a job writing to a directory nobody knows about is frequently what is filling the account.
Read what each one does before disabling any of it: an unrecognised job is not necessarily an unnecessary one. There is more on the WordPress side in why scheduled tasks do not run.
Look for the previous developer's access
Before changing anything else, find out who else can get in.
cat ~/.ssh/authorized_keys 2>/dev/null wp user list --role=administrator --fields=user_login,user_email 2>/dev/null
Plus the FTP account list and the panel's own user list. Departed developers, agencies and contractors are routinely still there, with working access nobody has thought about.
Remove what cannot be accounted for, but read it first, because one of those accounts may be what a scheduled job authenticates as. For the offboarding that was skipped, see managing FTP accounts.
Establish what the site actually does
The technical inventory says how it is built. It does not say what would be noticed if it stopped.
Ask the owner: what does this site do that matters, take orders, capture enquiries, publish, serve existing customers? Which of it happens automatically?
That answer determines everything about how carefully to proceed and what to test after any change. A brochure site tolerates an afternoon of experimentation; a site whose contact form is the only sales channel does not, and nothing in the file system tells you which one you have.