You have inherited a website.

Maybe the previous developer left. Maybe your company changed agencies. Maybe an employee who managed everything is gone. Maybe the website came with a business acquisition, a new job, or a project nobody else wanted to touch.

The site may still be online. That does not mean it is ready to manage.

Before changing the design, installing updates, replacing plugins, or moving anything, take time to understand what you now control and what you do not.

These ten steps will help you secure the important accounts, identify hidden dependencies, test the systems people rely on, and avoid creating a larger problem during the handoff. For a deeper explanation of how to investigate the full system, read our guide to taking over a website no one fully understands.

1. Confirm who owns the domain

Start with the domain name.

The domain controls where people find the website. It may also affect company email, verification records, subdomains, branded links, and third-party services.

Find out:

• Which registrar manages the domain
• Which account owns it
• Which email address receives renewal and recovery messages
• Whether the business has administrator access
• Whether multi-factor authentication is enabled
• Who pays for the renewal
• When the domain expires
• Whether the domain is locked against unauthorized transfers

Do not rely on someone saying the business owns the domain.

Log in and verify it.

A domain registered through a previous developer’s account may still work normally until the relationship ends, the credit card expires, or someone needs to change a DNS record.

The business should have direct access through an account it controls.

Do not assume that you own the domain just because you see the domain inside your account.

2. Get access to every service connected to the website

A WordPress or Shopify login is only one part of the handoff.

Create a list of every service that may support the site.

That list may include:

• Domain registrar
• DNS provider
• Web hosting
• Content management system
• Source-code repository
• Backup service
• Security service
• CDN
• Theme and plugin licenses
• Forms
• CRM
• Email delivery
• Analytics
• Google Tag Manager
• Search Console
• Advertising accounts
• Scheduling tools
• Payment processors
• Automation platforms
• API providers
• File storage
• Image libraries
• Cookie consent tools

For each account, record:

• What it does
• Who owns it
• Who pays for it
• Who currently has access
• Which email address is attached
• Whether multi-factor authentication is enabled
• Whether the service is still being used

Do not store passwords in an ordinary spreadsheet. Use a password manager.

The account inventory can still live in a document or spreadsheet, but the credentials should be stored securely.

3. Create a full backup before making changes

Do not begin with updates.

Do not begin by deleting old users.

Do not begin by moving the website to another host.

Create a complete backup first.

Depending on the platform, that may include:

• Website files
• Database
• Media library
• Theme files
• Custom plugins
• Configuration files
• Server settings
• Product data
• Customer records
• Order data
• Redirects
• Form entries
• Uploaded documents

Confirm where the backup is stored and whether it can be restored.

A backup inside the same hosting account may not help if the entire account becomes unavailable.

Whenever possible, keep an independent copy somewhere the business controls.

The backup should represent the current working state before cleanup begins.

4. Review users, passwords, and old access

Once the site is backed up, review who can still access it.

Look for:

• Former employees
• Previous agencies
• Freelancers
• Old developers
• Unknown administrator accounts
• Shared logins
• Generic usernames
• SFTP users
• SSH keys
• Repository collaborators
• Hosting users
• Analytics users
• Tag Manager users
• CRM users
• API credentials

Do not remove accounts blindly.

An old account may own a critical integration, license, automation, or recovery method.

First determine what depends on it. Then transfer ownership or replace credentials where necessary.

For shared or sensitive accounts:

• Change passwords
• Enable multi-factor authentication
• Update recovery details
• Create named user accounts
• Remove access that is no longer needed

The goal is to leave the business with clear control without breaking a system that still relies on an old identity.

5. Identify what is custom

An inherited website may look ordinary while relying on custom code behind the scenes.

Review the site for:

• Custom themes
• Child themes
• Custom plugins
• Theme-file edits
• Code-snippet plugins
• Must-use plugins
• Custom templates
• Custom post types
• Custom database tables
• Scheduled tasks
• Webhooks
• API connections
• Conditional logic
• Custom checkout behavior
• User account workflows
• Hardcoded credentials
• Custom redirects
• Server-side scripts

This matters because a standard plugin may only be the visible part of a larger workflow.

For example:

• A form plugin may save entries while custom PHP sends the data elsewhere.
• A theme may display content using custom fields that are not visible in the normal editor.
• A booking system may rely on tracking code added directly to a template.
• A CRM connection may depend on a webhook stored in an automation platform.

Do not remove something because it appears inactive in the dashboard.

Confirm what it does first.

6. Test the workflows people depend on

Do not assume a feature works because it looks normal.

Test the important user journeys from beginning to end.

That may include:

• Contact forms
• Quote requests
• Appointment scheduling
• Account registration
• Password resets
• Payments
• Orders
• Donations
• Downloads
• Newsletter signup
• Internal notifications
• Customer confirmation emails
• CRM record creation
• Lead assignment
• Analytics events
• Advertising conversions

Use real test data and document what happens at each step.

For a form, confirm:

1. The visitor can submit it.
2. The submission is saved somewhere.
3. The correct staff member receives it.
4. The CRM creates or updates the record.
5. The visitor receives the expected confirmation.
6. Analytics records the event.
7. Advertising platforms receive the correct conversion.

A success message on the website only confirms part of the process. The later steps may fail quietly, especially when every vendor says its system works but the complete workflow still fails.

7. Check hosting, updates, licenses, and support status

Review the technical environment before deciding whether to update anything.

Check:

• CMS version
• Server version
• PHP version
• Database version
• Theme status
• Plugin or app status
• Available updates
• Security warnings
• Expired licenses
• Unsupported software
• Abandoned plugins
• Hosting storage
• Error logs
• Backup schedule
• Staging availability

An update notification does not guarantee that updating is safe.

Older sites may contain custom code written around a specific plugin or platform version. A routine update can break templates, forms, account systems, or integrations. When that happens repeatedly, the website may be too fragile to keep repairing safely.

Classify each item:

• Safe to update
• Needs testing
• Requires replacement
• Appears unused but needs investigation
• Critical and currently unsupported

Use staging for significant changes whenever possible.

8. Verify analytics, search, and conversion tracking

Inherited analytics setups are often messy.

The site may contain:

• Multiple GA4 properties
• Duplicate Google Tag Manager containers
• Old Universal Analytics tags
• Hardcoded advertising pixels
• Test conversion actions
• Broken thank-you-page tracking
• Events firing more than once
• Events that never fire
• Tracking installed inside an embedded platform
• Missing cross-domain tracking

Check:

• Which GA4 property is active
• Whether Tag Manager is installed
• Whether tags are duplicated
• Which events count as conversions
• Whether real leads appear in reports
• Whether purchases are recorded correctly
• Whether Google Ads imports the right actions
• Whether Search Console access is current
• Whether high-value pages still receive traffic
• Whether redirects are preserving old URLs

Separate the business outcome from the measurement.

A lead can reach the sales team while Google Ads reports nothing.

A conversion event can fire even though no real lead was created.

You need to know which problem you are dealing with before changing the site.

9. Document what should not be changed yet

Some parts of the website may be risky to touch until more investigation is complete.

Create a temporary “do not change” list.

That may include:

• Unknown plugins
• Custom theme files
• Payment settings
• Form actions
• CRM workflows
• DNS records
• Email authentication
• Scheduled tasks
• Webhook URLs
• API keys
• Redirect rules
• Checkout scripts
• Tracking code
• User-role settings
• Database tables

Add a short explanation for each item.

For example:

Do not disable Plugin X until the account-creation workflow is mapped.

Do not replace the thank-you page until Google Ads tracking is confirmed.

Do not change DNS until website and email records are documented.

This prevents a well-meaning cleanup from breaking something the business still needs.

10. Decide what should happen next

Once the website is backed up, documented, tested, and reviewed, decide what kind of work it actually needs. Our guide to choosing between repair, rebuilding, and migration explains how to evaluate those options in more detail.

The next step may be:

Stabilization

Choose stabilization when the website is functioning but lacks reliable backups, clear ownership, secure access, current licenses, or documentation.

Repair

Repair makes sense when the problems are contained, and the underlying system remains healthy.

Examples include:

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

Rebuild

A rebuild may be appropriate when the platform still fits the business, but the implementation has become too fragile or difficult to maintain.

Common signs include:

• Updates regularly break unrelated features
• The theme or codebase is unsupported
• Routine edits require development work
• Customizations are spread across too many places
• Accessibility and performance problems are structural
• Nobody can safely maintain the current setup

Migration

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

That may involve:

• Limited data access
• Unsupported workflows
• Integration restrictions
• Excessive platform costs
• Vendor lock-in
• No viable maintenance path
• A discontinued or abandoned platform

The safest decision comes after the current system is understood.

A simple inherited website checklist

Before approving major changes, confirm that you have reviewed:

Ownership

• Domain
• DNS
• Hosting
• CMS
• Source code
• Licenses
• Billing accounts

Security

• Administrator users
• Passwords
• Multi-factor authentication
• Recovery emails
• Former vendor access
• Backup and restore process

Technical setup

• Theme
• Plugins or apps
• Custom code
• Server environment
• Staging
• Scheduled tasks
• APIs
• Webhooks

Business systems

• Forms
• CRM
• Payments
• Scheduling
• Email delivery
• User accounts
• Automations
• Internal notifications

Search and measurement

• GA4
• Google Tag Manager
• Search Console
• Google Ads
• Meta tracking
• Redirects
• High-value pages
• Conversion events

Documentation

• Account owners
• Vendor contacts
• Renewal dates
• Critical dependencies
• Known problems
• Previous fixes
• Items that should not be changed

Common mistakes to avoid

Updating everything immediately

A large batch of updates makes it difficult to identify which change caused a failure.

Review and test first.

Deleting old accounts before transferring ownership

An old user may own licenses, integrations, automations, or recovery methods.

Transfer what is needed before removal.

Moving hosting before mapping DNS and email

A hosting migration can affect much more than the website.

Document DNS, email, subdomains, SSL, and connected services first.

Rebuilding because the current site feels inconvenient

Inherited work often feels awkward because it is unfamiliar.

That alone is not enough reason to replace it.

Assuming a green dashboard means the workflow works

Vendor dashboards usually show the health of one system.

Test the full business outcome.

Trusting the editor as a complete view of the site

The editor may not reveal custom templates, integrations, code, routing logic, or server-level settings.

When professional help makes sense

A straightforward brochure site may be manageable with a careful handoff and normal maintenance.

A deeper technical review is worth considering when the business needs help securing, documenting, stabilizing, or assuming responsibility for the existing system. Kismet provides inherited website takeover and technical rescue support for those situations.

• The site contains custom functionality
• Several vendors or platforms are involved
• Ownership is unclear
• Important access is missing
• The site cannot be updated safely
• Business-critical workflows are failing
• Nobody can explain how the complete system works
• A rebuild or migration has been proposed
• A wrong change could affect leads, payments, customers, or operations

Kismet’s Technical Website Assessment is designed for situations where the current system needs to be investigated before repair, rebuilding, migration, or takeover work begins.

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 another qualified provider.

—

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.