Taking Over a Site Somebody Else Built
You have been handed a site with no documentation, or with documentation that describes a version that no longer exists. Everything you actually need can be established from outside in about an hour, and doing it before you change anything gives you a baseline that is worth more than it sounds.
What is it built on
Start with what the site tells strangers about itself: framework, server software, CMS, analytics, CDN, and often exact version numbers. This is the same reconnaissance anyone else can do, and on an inherited site it is usually more accurate than anything you will be told. A version banner naming a release with published vulnerabilities is a finding on its first day.
What is going to expire
Certificates and domain registration, on every hostname you can find rather than the main one. Inherited sites are where lapsed renewals live, because the notifications go to an address belonging to somebody who left. This is the single highest-value hour of the handover: an expiry you find now is a calendar entry, and the same expiry found later is an outage.
If it is a CMS, what is installed
For WordPress or Drupal, enumerate the plugins and modules from outside and check them against known vulnerabilities. The vulnerability is almost never in core, which updates itself — it is in a plugin installed for a campaign in 2019 that is still active and has not been touched by its author since. On an inherited site, assume this until proven otherwise.
What is exposed
Probe the paths that should never be public: environment and configuration files, version control directories, admin panels, debug endpoints, status pages. These arrive through ordinary deployment mistakes and they are probed constantly by automated scanners, so the window between exposure and discovery by someone else is short. An exposed environment file means the credentials in it should be treated as already compromised.
What is already broken
Crawl for broken links and load the main pages in a real browser to see what they actually pull in. Both produce a list you did not create, which is useful in two ways: it tells you the current state, and it gives you something concrete to show whoever handed the site over — a list of pre-existing problems established before you touched anything is a genuinely valuable document.
Record it before you change anything
The reason to do all of this on day one is not just to find problems. It is to have a recorded baseline, so that when something breaks in three weeks you can tell whether it was like that when you arrived. Without one, every subsequent problem is implicitly yours. Setting the same checks to run on a schedule from the start means the baseline maintains itself rather than being a document that is out of date by the second week.