Thirty Days to Clarity: How to Audit a Website You Didn't Build

Somewhere in the United States this morning, a marketing director is logging into a company website for the first time and discovering that nobody knows the FTP password. The developer left two years ago. The agency that built the site dissolved after a merger. The domain registrar account belongs to someone's personal Gmail address.

This scenario plays out daily across industries, and it rarely ends well when handled impulsively. The instinct to immediately rebuild is expensive; the instinct to leave everything untouched is risky. What businesses need instead is a disciplined, methodical audit.

Week One: Establish Control Before You Change Anything

The first priority is not improving the website. It is ensuring no one else can destabilize it.

Begin by inventorying every credential: hosting accounts, domain registrar access, CMS administrator logins, CDN dashboards, email service accounts, and any connected payment methods. Expire the access of anyone who no longer needs it, and route all recovery emails to monitored company addresses rather than personal inboxes.

Two-factor authentication should be enabled on every administrative account during this first week. It is remarkable how many inherited websites still authenticate through a single shared password that has been forwarded between employees in plain-text emails for years.

Week Two: Map What You Actually Own

With access secured, the second week is about documentation — specifically, creating the documentation your predecessor never wrote.

List every plugin, extension, module, and third-party integration currently running. For each one, record three things: what it does, who maintains it, and when its license expires. Inherited websites routinely carry paid plugins on lapsed licenses, which means updates have silently stopped arriving. A security patch released eighteen months ago does nothing for a site that cannot download it.

Pay particular attention to anything connecting the website to revenue: payment gateways, booking systems, inventory feeds, and CRM integrations. These are the components where an undocumented failure becomes a business interruption rather than a technical nuisance.

Week Three: Separate the Red Flags From the Noise

Not every problem on an inherited website demands urgent action, but certain findings should escalate immediately:

• Software versions that are years behind. If the core platform or PHP runtime has not been updated in multiple release cycles, the site is likely exposed to publicly documented vulnerabilities.
• Admin accounts belonging to people who are gone. Former employees and agency staff retaining administrative access is both a security risk and, in some industries, a compliance problem.
• No accessible backups — or backups stored on the same server as the site. Either condition means a single hardware failure or ransomware event could erase the business's entire web presence.
• Hardcoded credentials in theme files or scripts. This is common in freelance-built sites and makes future transitions painful.
• Analytics that don't match reality. If traffic reporting has been misconfigured for years, every historical performance assumption the business holds may be wrong.

Week Four: Make the Keep-or-Rebuild Decision

Only after four weeks of documentation should the rebuild question be answered, and the answer usually follows a simple pattern.

A workable foundation typically shows current-enough software, a maintained plugin ecosystem, clean access control, and a design that still serves the business's positioning. In that case, incremental investment — better hosting, professional backups, a maintenance retainer — delivers strong returns.

A rebuild candidate shows the opposite: abandoned platforms, unfixable code, security exposure that costs more to remediate than to replace, or a design that no longer reflects the company it represents.

The Conversation You May Not Be Able to Have

Ideally, you would call whoever built the site and ask questions. Sometimes that person is reachable and cooperative. Often they are not — departed, retired, or legally entangled with a former employer.

When the builder is unavailable, your documentation from the first three weeks becomes the substitute conversation. Every credential recovered, plugin identified, and risk catalogued is knowledge that would otherwise leave with the person who built it.

Inherited websites are not doomed. They are simply undocumented, and documentation is a solvable problem — provided you solve it deliberately rather than discovering its absence during an outage.