WordPress site unfinished? How to take stock and get it finished

WordPress runs a huge share of the web, so when a site is left half-done there is almost always someone who can finish it. The hard part is usually not the remaining work itself but the unknowns: who has the logins, which plugins are holding things together, whether there is a backup, and what the last person changed. This page helps you answer those questions before a new developer starts, which saves time and money for both of you.

First, secure access and a backup

Before anything else is touched, make sure you control the site and have a copy of it.

• Domain registrar: you can log in, and the domain is registered to you.
• Hosting account: you are the account owner, not just a user someone else added.
• WordPress admin: you have an administrator account of your own.
• Database and files: you can reach them through the host's control panel, SFTP or a file manager.
• Backup: a complete, recent backup of both files and database exists, stored somewhere other than the same server.

If a previous developer or agency still holds some of these, see what to do when an agency abandons a project, and the guide on securing your accounts after a developer disappears walks through recovering each one. While you are in the WordPress admin, open Users and look for administrator accounts you do not recognise. Downgrade or remove any that should not be there, and change your own password.

Take stock of the build

Theme and page builder

Find out which theme is active (Appearance, then Themes) and whether it is a child theme. Then note how pages are built: the block editor, Elementor, Divi, WPBakery, Beaver Builder or something else. Mixing builders across pages is common in unfinished sites and makes later edits harder. A developer will want to know which builder you prefer to keep, because that choice shapes the rest of the work.

Child themes and custom code

If custom PHP, CSS or template changes were made directly to the main theme, they will be lost at the next theme update. Look in Appearance for a theme name ending in "Child". If there is none and the theme has clearly been altered, flag it. Custom code may also live in a "code snippets" plugin or in a small custom plugin, so mention any you see.

Plugins and conflicts

Open the Plugins page and record every plugin, whether it is active, and whether an update is waiting. Many unfinished sites have too many plugins, several doing the same job, or plugins that clash after an update. The symptoms include blank pages, broken layouts, a "critical error" message, or admin screens that will not load.

The official Health Check and Troubleshooting plugin can switch plugins off for your session only, which helps narrow down a conflict without breaking the site for visitors. A developer will also turn on WordPress debug logging in a safe way to see the real error messages.

Licences for premium themes and plugins

Paid themes and plugins need a valid licence for updates. Check who bought them and on which account. Nulled (pirated) versions are a frequent source of hidden malware and should be replaced with properly licensed copies.

WooCommerce

If the site sells anything, check the parts that touch money and orders carefully:

• Payment gateways: are they in test mode or live mode, and whose account receives the money?
• Shipping zones and tax settings: do they match where and how you actually sell?
• Order emails: do customers and you receive them, and do they land in spam?
• Extensions: are they up to date and compatible with your WooCommerce version and its current order storage system?
• A test order from start to finish, refund included.

Staging

A staging site is a private copy where changes can be tested before going live. Many hosts offer one-click staging; otherwise a developer can set one up. For a shop or a site with live traffic, all major work should happen on staging first.

Rescue or rebuild?

Finishing usually makes sense when the theme is reasonably standard, customisations can be moved into a child theme, and the plugins are maintained. A rebuild is worth discussing when the site depends on abandoned or unlicensed plugins, the theme has been heavily edited with no record of the changes, or the page builder is so tangled that each edit takes hours. The rescue effort estimator gives a rough starting point, and the guide on what to check first in WordPress and Shopify takeovers looks at the decision from the developer's side.

What a rescue developer will typically check first

Most developers taking on a WordPress site will:

1. Take their own full backup and confirm it restores.
2. Set up staging, or confirm the existing staging site matches live.
3. Check WordPress, PHP, theme and plugin versions, and scan for malware or unknown files.
4. Review administrator users, file permissions and the security of the login page.
5. Turn on debug logging on staging and work through errors and conflicts.
6. Walk the key user journeys: contact forms, sign-up, checkout and email delivery.

They will ask for their own administrator account and, where your host allows it, their own hosting or SFTP user. The guide on giving a developer access without sharing passwords shows how. When the work is done, remove those accounts. The handover checklist generator helps you list everything to transfer and check.

Post your WordPress takeover

If you want someone to finish the site, post it on TakeoverWork. Posting is free. Include the theme and page builder, a rough plugin count, whether WooCommerce is involved, what is done and what is missing, and whether you have backups and full access. Do not add passwords or licence keys to the listing.

TakeoverWork connects site owners with developers and agencies who finish started projects. It does not check, employ or supervise anyone, and it never handles project money, so agree the scope and payment terms directly with the person you choose.