The website is online.

Customers are using it. Forms are submitting. Maybe orders are still coming through.

Nobody wants to touch it.

The previous developer is gone. The agency relationship ended. An employee who managed the site left the company. There is no documentation, no clear list of accounts, and no one knows which parts of the website are connected to other systems.

This situation is more common than it should be.

A website can keep functioning for years after the people who built it are no longer involved. That does not mean the system is healthy. It may be relying on expired licenses, former employee accounts, abandoned plugins, hardcoded credentials, or integrations nobody remembers setting up.

The first step is not redesigning it.

The first step is understanding what you inherited. For an immediate sequence of actions, start with these 10 things to do when you inherit a website.

Start by assuming the website is larger than the website

Most businesses think of the website as the thing they see in the browser.

The visible pages are only one part of it.

A typical business website may also depend on:

• A domain registrar
• DNS hosting
• Web hosting
• A content management system
• Theme and plugin licenses
• Forms
• Email delivery services
• CRM connections
• Analytics
• Google Tag Manager
• Search Console
• Advertising conversion tracking
• Payment systems
• Scheduling tools
• Automation platforms
• API keys
• Webhooks
• Source-code repositories
• Staging environments
• Backup systems
• Security tools
• Content delivery networks

Some of those services may be owned by the business.

Others may belong to the former agency, a previous employee, an outside IT company, or an account nobody can identify.

That is why taking over a website is rarely as simple as creating a new WordPress administrator.

Do not begin by updating everything

One of the first things a new developer may be tempted to do is update the CMS, theme, and plugins.

That can be reasonable on a well-documented website.

On an inherited website, it can create a serious problem.

An update may break:

• Custom theme changes
• An old page builder
• A form integration
• Payment processing
• Scheduling
• User accounts
• A custom plugin
• A third-party API
• Tracking
• Email notifications
• Server compatibility

The fact that a plugin says an update is available does not tell you whether the rest of the system can support it.

Before changing anything, create a reliable backup and confirm that the backup can actually be restored.

A backup that has never been tested is only a theory.

Secure ownership and access first

Before evaluating code, design, or performance, confirm who controls the essential accounts.

The most important places to start are:

Domain registrar

The registrar controls ownership of the domain.

Confirm:

• The business is listed as the registrant
• The account uses a current company email address
• Multi-factor authentication is enabled
• Recovery information is current
• Renewal billing is not tied to a former vendor
• The domain is not locked inside an agency-owned account

Losing access to the website is inconvenient.

Losing control of the domain is much worse.

DNS provider

DNS determines where the domain sends website, email, verification, and other service traffic.

The DNS provider may be the registrar, web host, CDN, email platform, or another company.

Document the current records before making changes.

A DNS mistake can affect:

• The website
• Company email
• Subdomains
• Email authentication
• Verification records
• Third-party services
• Tracking or branded links

Hosting

Confirm:

• Which company hosts the site
• Who owns the hosting account
• Who receives billing notices
• Whether the business has direct access
• Whether staging is available
• Where backups are stored
• Which PHP, database, or server versions are in use
• Whether server-level configuration has been customized

Do not assume the hosting company has a complete understanding of the website. It may only maintain the infrastructure.

CMS access

Create individual administrator accounts for the people who need them.

Avoid relying on one shared account with a password everyone knows.

Review the current users and remove or restrict accounts that no longer need access. Pay special attention to:

• Former employees
• Old agencies
• Freelancers
• Generic administrator accounts
• Accounts with unfamiliar email addresses

Source code

Some websites contain important code that does not live entirely inside the CMS.

Ask whether there is:

• A GitHub, GitLab, or Bitbucket repository
• A local development copy
• A deployment process
• A custom plugin repository
• A child theme
• Server-level scripts
• Scheduled tasks
• Custom configuration files

If the live website is the only remaining copy of the code, that should be documented immediately.

Build an account inventory

Create one list containing every service associated with the website.

For each item, record:

• Service name
• Purpose
• Account owner
• Login email
• Billing owner
• Access level
• Multi-factor authentication status
• Renewal date
• Vendor contact
• Whether the service is still in use
• Which other systems depend on it

Do not store raw passwords in a normal spreadsheet.

Use a proper password manager and record the account details separately.

This process often reveals issues before a developer even reviews the code.

I have seen websites where:

• A form integration belonged to a former employee
• Plugin licenses were tied to an old agency account
• Analytics access existed, but nobody had administrator rights
• The company owned the hosting but not the domain
• A live site was sending data to a test CRM
• The only working automation ran through someone’s personal account
• Email delivery depended on credentials nobody could identify

The website may look like one system. Operationally, it may be a collection of unrelated accounts held together by history.

Map what the website connects to

Once ownership is clearer, document the website’s external connections.

Start with the business processes people depend on.

Ask:

• Where do contact forms go?
• Does the website send leads into a CRM?
• How are leads assigned?
• Where are confirmation emails sent from?
• Does the website accept payments?
• Does money go to one account or several?
• Is scheduling embedded or handled externally?
• Are customer accounts stored on the website?
• Does inventory synchronize with another system?
• Are form responses routed differently based on the answers?
• Does the website create tasks, tickets, or notifications?
• How are conversions reported to advertising platforms?
• Does the site depend on any private API?

A simple workflow diagram is often enough.

For example:

Website form → webhook → automation platform → CRM → staff notification

Or:

Website → embedded booking system → payment processor → confirmation page → GA4 → Google Ads

If nobody can explain the full workflow, changing one part of it becomes risky. The problem becomes even harder when every vendor says its system works but the complete process still fails.

This is especially important when several vendors are involved. Each company may understand its own platform while nobody has visibility across the entire process.

Identify what is custom

Custom work is not automatically a problem.

Undocumented custom work is.

Look for:

• Custom themes
• Child themes
• Custom plugins
• Theme file changes
• Code-snippet plugins
• Must-use plugins
• Custom database tables
• Hardcoded API endpoints
• Custom post types
• Custom user roles
• Scheduled tasks
• Webhooks
• Server-side scripts
• Custom checkout behavior
• Form-processing code
• Conditional email routing
• Data imports and exports

In WordPress, a plugin list does not tell the full story.

A website may use a standard form plugin while custom PHP controls where submissions go. A page builder may be standard while the theme contains custom templates that depend on specific field names. A custom post type may feed another system through an API.

Removing what looks like an unused component can break something that lives elsewhere.

The same applies to Shopify, custom applications, and proprietary platforms. A theme may contain scripts connected to product data, external services, or tracking systems that are not obvious in the visual editor.

Find the fragile parts before they find you

An inherited website often contains warning signs that deserve attention even when the site appears stable. Some of those warning signs can indicate that the website has become too fragile to keep repairing.

Unsupported software

Look for:

• Plugins that have not been updated in years
• Themes that no longer receive support
• Old CMS versions
• Unsupported PHP versions
• Deprecated APIs
• Abandoned integrations

Unsupported software may continue working until another system changes around it.

Expired or missing licenses

Premium plugins and themes may keep functioning after a license expires, but the site may lose:

• Security updates
• Compatibility updates
• Support
• Access to downloads
• Cloud-based features

Confirm whether each license belongs to the business or the former provider.

No safe update process

A healthy website should have some way to test significant changes before they affect the live site.

Warning signs include:

• No staging site
• No recent backup
• No deployment process
• Direct edits to production
• No record of previous changes
• No way to identify who changed what

Hidden dependencies

A plugin may appear unused because it has no visible settings page.

It may still provide a shortcode, scheduled task, API route, template function, or integration another part of the site requires.

Disable components only after confirming what depends on them.

Former vendor access

Old agencies and developers sometimes retain access long after the relationship ends.

That is not always malicious. Nobody may have thought to remove it.

Review:

• CMS users
• Hosting users
• SFTP accounts
• SSH keys
• Repository collaborators
• Analytics users
• Tag Manager users
• DNS access
• Cloud service accounts
• API credentials

Remove access carefully and replace shared credentials when necessary.

Preserve what already has value

Inherited websites are often treated as disposable because they are frustrating to manage.

That can be expensive.

The existing site may already have:

• Pages that rank well
• Valuable backlinks
• Years of published content
• A functioning URL structure
• Useful analytics history
• Conversion tracking
• Customer accounts
• Product data
• Forms people rely on
• Internal workflows
• Search visibility the business does not realize it has

Before proposing a rebuild or migration, identify what is working.

Review:

• Google Search Console
• GA4
• Google Ads conversions
• High-traffic pages
• High-converting pages
• Backlinks
• Indexed URLs
• Redirects
• Metadata
• Structured data
• Downloaded files
• Landing pages used in campaigns

A technically messy website can still contain valuable digital assets.

Rebuilding without documenting them first can trade one problem for another.

Check whether tracking can be trusted

Analytics and advertising accounts are often inherited along with the site.

Do not assume the reports are accurate.

Check:

• Whether GA4 is installed once or several times
• Whether Google Tag Manager is in use
• Whether hardcoded tags remain in the theme
• Which events count as conversions
• Whether forms trigger duplicate events
• Whether embedded tools pass conversion data correctly
• Whether test submissions are being counted
• Whether thank-you pages remain accessible without submitting
• Whether Google Ads imports the correct GA4 events
• Whether phone clicks are treated as completed calls
• Whether cross-domain tracking is configured
• Whether old conversion actions remain active

I regularly see accounts where traffic is being measured, but the business outcome is not.

I also see the opposite. The lead or purchase succeeds, but the tracking does not.

Those are different failures.

Before making major changes, understand what is currently being measured and whether it reflects reality.

Review email delivery separately

Form notifications are often blamed on the website when the real problem lives in email delivery.

Document:

• Which service sends website email
• The sending domain
• SPF records
• DKIM records
• DMARC policy
• SMTP or API credentials
• Suppression lists
• Recipient rules
• Internal distribution groups
• CRM notification settings

A form can save the submission successfully while the notification fails.

That distinction matters because replacing the form will not fix an email-authentication problem.

Do not trust the visual editor alone

Visual editors show what content managers are allowed to see.

They do not necessarily reveal:

• Custom templates
• Hidden fields
• Query logic
• Dynamic content
• API calls
• Server configuration
• Conditional workflows
• Theme-level scripts
• Redirects
• Scheduled tasks
• Code running through another plugin

A proper takeover requires looking beyond the page editor.

That does not mean every inherited website needs a deep forensic investigation. It means the scope should match the risk.

A basic brochure site may only need access review, backups, updates, and documentation. A site connected to payments, scheduling, CRMs, user accounts, or custom workflows may justify an independent technical website assessment before changes begin.

A site connected to payments, scheduling, CRMs, user accounts, or custom workflows deserves a more careful assessment.

Stabilize before improving

Once the system is understood, the next phase may be stabilization.

That can include:

• Creating reliable backups
• Confirming a restore process
• Securing ownership
• Removing obsolete access
• Renewing critical licenses
• Updating low-risk components
• Creating staging
• Fixing immediate errors
• Documenting integrations
• Correcting email delivery
• Repairing broken tracking
• Monitoring important workflows

Stabilization is not the same as redesigning or rebuilding.

It gives the business a safer foundation for future decisions.

Sometimes this is enough.

An inherited website may be ugly, awkward, or poorly documented while still being fundamentally usable. Once ownership, backups, updates, and documentation are addressed, the business may be able to improve it gradually.

Decide whether to repair, rebuild, or migrate

Our full guide to deciding whether to repair, rebuild, or migrate a website explains the differences, warning signs, and risks in more detail.

After the investigation, the website usually falls into one of several paths.

Stabilize

Choose stabilization when the site works but lacks documentation, secure access, reliable backups, or basic maintenance controls.

Repair

Repair makes sense when the platform and implementation are mostly sound, but specific problems need to be corrected.

Examples include:

• A broken form
• Incorrect routing
• Performance issues
• A failed integration
• Email delivery problems
• Tracking errors
• A limited number of template problems

Rebuild

Rebuild when the platform still fits the business, but the current implementation has become too fragile or difficult to maintain.

Examples include:

• An unsupported theme
• Conflicting plugins
• Undocumented custom code
• Poor content structure
• Widespread accessibility problems
• Routine updates breaking unrelated features
• Editing that requires constant developer help

Migrate

Migration makes sense when the platform itself prevents the business from accomplishing what it needs.

Examples include:

• No access to required data
• Unsupported business workflows
• Severe platform limitations
• Unreasonable transaction or licensing costs
• Dependence on an unreliable vendor
• No viable integration path
• Software that is no longer maintained

A takeover investigation should give you enough evidence to distinguish among those options. Kismet provides inherited website takeover and technical rescue support for businesses that need help securing, documenting, stabilizing, or replacing an existing system.

Without that work, a rebuild recommendation may only be a guess.

What a new developer should ask before quoting major work

Be cautious when someone recommends a complete rebuild after reviewing only the public website.

A responsible developer should ask about:

• Domain and hosting ownership
• CMS access
• Existing integrations
• Forms
• CRM
• Email delivery
• Payments
• Scheduling
• User accounts
• Analytics
• Conversion tracking
• Search Console
• Advertising campaigns
• Custom code
• Business-critical workflows
• Current problems
• Previous repair attempts
• Required functionality
• Search performance
• Existing content

A homepage screenshot cannot answer those questions.

The person quoting the project should understand what must survive the work.

An anonymized rescue: the website was only one piece

One organization came to us with a website workflow that appeared relatively straightforward.

A form needed to collect information, route it correctly, send the appropriate emails, and update external systems.

The visible form was only the front end.

The complete process involved:

• Conditional form logic
• Different notification paths
• User account creation
• Custom content records
• An external platform
• Internal review
• Automated emails
• Ongoing account management

The risk was not simply whether the form could be rebuilt.

The risk was whether a change to the form would quietly break one of the later steps.

We had to map the entire process before making changes.

That investigation made the implementation safer and prevented the organization from solving only the visible portion of the problem.

Another rescue: the front end and editor told different stories

In another situation, a client’s website editor appeared to contain the correct settings.

The front end showed something else.

The immediate assumption was that the content had not been saved or the user was editing the wrong template.

The actual problem involved how theme settings, fallback values, and front-end code interacted.

Replacing the content would not have helped. Rebuilding the whole section would have been unnecessary.

The fix required understanding how the existing system was designed to choose between editor settings and fallback content.

This is common in inherited websites.

The visual symptom may be simple. The cause may live in a template, data field, cache, integration, or conditional rule.

Website takeover checklist

The following checklist summarizes the major areas to review. For a step-by-step sequence, use our 10-step inherited website checklist.

Before making significant changes, confirm the following.

Ownership and accounts

• Domain registrar
• DNS provider
• Hosting
• CMS
• Source-code repository
• Backup service
• Security service
• CDN
• Plugin and theme licenses

Website systems

• Forms
• CRM
• Email delivery
• Scheduling
• Payments
• E-commerce
• User accounts
• Memberships
• Search
• Analytics
• Advertising tracking

Technical details

• CMS version
• Server environment
• Theme
• Child theme
• Custom plugins
• Code snippets
• Database customizations
• Scheduled tasks
• Webhooks
• APIs
• Staging site
• Deployment process

Business workflows

• Lead routing
• Customer confirmations
• Internal notifications
• Payment flow
• Account creation
• Staff review
• Data synchronization
• Reporting
• Follow-up automations

Search and measurement

• GA4
• Google Tag Manager
• Search Console
• Google Ads conversions
• Meta Pixel
• Redirects
• Indexed pages
• High-value content
• Structured data
• Cross-domain tracking

Documentation

• Account owners
• Vendor contacts
• Renewal dates
• Critical dependencies
• Recovery process
• Known problems
• Previous fixes
• Change history

When a technical assessment is worth it

You do not need a full technical assessment every time a business changes developers.

It becomes worthwhile when:

• The website contains custom functionality
• Several platforms are connected
• Ownership is unclear
• Documentation is missing
• The site cannot be updated safely
• Previous developers left unfinished work
• Important workflows are failing
• The business is considering a rebuild or migration
• Nobody can explain how the complete system works
• A wrong decision could affect revenue, customer data, or operations

Kismet’s Technical Website Assessment is designed for this kind of situation.

We review the current setup, document the systems involved, identify immediate risks, and recommend whether the next step should be stabilization, repair, rebuilding, or migration.

The assessment is separate from implementation. You can use the findings with Kismet or take them to another qualified provider.

That separation matters when you need an honest recommendation before committing to a major project.

—

Still unsure which path makes sense?

A Technical Website Assessment can identify the source of the problem, document the available options, and give you a practical implementation roadmap.

Request a Technical Assessment

—

Written by Joey Zuccarini
COO at Kismet Creative Co.