The site is gone and there is no backup. That is less final than it feels, several copies usually exist that nobody counted, and the order you look in matters.
Stop first
Change nothing. Do not reinstall WordPress over the top, do not start deleting, do not run a repair tool.
Everything below depends on the current state, and the most common way a recoverable situation becomes unrecoverable is somebody trying to fix it in the first ten minutes.
Ask the host
Many hosts keep backups as part of the service, whether or not the customer arranged anything. Retention is often short: days rather than weeks, which makes this urgent rather than optional.
Ask specifically what exists and for which dates. If a backup exists, restoring to a separate location first is safer than over the top. Restoring a website goes into the order and the scope decision.
Check whether the database survived
File loss and database loss are separate events, and people report "the site is gone" for either.
This matters enormously: the content lives in the database. Posts, pages, settings, users, comments. If the database is intact and only files were lost, the site is rebuildable: WordPress itself and most plugins can be downloaded again.
Look in phpMyAdmin. If the tables are there with rows in them, most of the site still exists. There is more on exporting it immediately, which is the first thing to do once you know it is there in managing MySQL databases with phpMyAdmin.
The reverse is also survivable: files intact and database lost means the theme and uploads exist, and the content does not.
Look for copies nobody counted
Several usually exist.
A staging site. Frequently a subdomain or subdirectory nobody has thought about for months, containing a complete copy from whenever it was made.
A migration archive. Sites moved between hosts leave the export behind. Look for large ZIP or SQL files in the account, including above the web root.
An old backup plugin's output. A plugin installed once and forgotten may have written into wp-content for months.
find ~ -maxdepth 4 -type f \( -name "*.sql" -o -name "*.zip" -o -name "*.tar.gz" \) -size +1M 2>/dev/null | head -20
A developer's machine. Anyone who worked on the site probably has a local copy. It is old and it is a site.
Uploads are worth checking separately
Even after a compromise or a partial deletion, wp-content/uploads is frequently intact, and it holds every image ever added.
Images are the part that cannot be rewritten, so if that directory survived, the recovery is substantially easier than it looked.
The last resort
Search engine caches and internet archives hold rendered copies of public pages.
That recovers text, page by page, by hand. It rarely recovers images at full size, does not recover structure or settings, and does not recover anything behind a login.
It is slow and it is genuinely better than nothing for a content site whose value was the writing.
If it was a compromise instead of a deletion
Do not restore and stop. A site restored to a point that was already infected is infected again, and the entry point is still open.
Restore, change every password, update everything, then find how they got in. Cleaning up a hacked WordPress site sets out the sequence.
Then set up backups properly
This is not a lecture; it is the only part of this page that prevents a repeat.
Whatever you recover, back it up today, off the server, tested once by restoring it somewhere: before doing anything else with the site.
Managing WordPress backups goes into what to capture and how long to keep it, and the restore test is the part that distinguishes a backup from an assumption.
Look in the places that keep copies without being asked
A site with no backup frequently has several partial ones, created by systems nobody thinks of as backups.
ls -la ~/tmp ~/backups ~/public_html/*.zip ~/public_html/*.sql 2>/dev/null find ~ -maxdepth 3 -name '*.sql*' -o -maxdepth 3 -name '*.tar.gz' 2>/dev/null | head ls -la ~/.trash 2>/dev/null | head
Update plugins keep a copy of what they replaced. Migration tools leave an archive behind. A security plugin may hold a scan snapshot. Each is partial and each is better than nothing.
Ask the host as well, and ask specifically rather than generally. A server level backup may exist for their own purposes with a short retention, and it is available only if you ask before it rotates.
Rebuild the content from what is public
Where the database is gone, the pages themselves may be recoverable from outside the server.
Search engine caches, archive services and any feed the site published all hold text. Between them, a small site's content can frequently be reassembled, which is slow and considerably better than starting from nothing.
curl -s https://example.com/sitemap.xml | grep -c 'loc' 2>/dev/null curl -s "https://web.archive.org/cdx/search/cdx?url=example.com*&output=text&limit=50" 2>/dev/null | head
Capture the address list first. Knowing which pages existed is what makes the rest systematic rather than a matter of remembering.
Set up the backup before doing anything else
The recovery is not finished when the site is back. It is finished when the same event cannot happen again.
ls -la ~/backups/ 2>/dev/null crontab -l | grep -i backup
Arrange it the same day, while the cost of not having one is still vivid. A month later it will be somebody's intention rather than a job that runs.
And confirm the first one by restoring it somewhere else. An untested backup is the state you were just in, with a file that makes it feel otherwise. Managing WordPress backups covers the arrangement.
Write down what you lost and what it cost
The recovery is the moment when the value of a backup is obvious, and that clarity fades within a month. Record what was lost, how long the site was down, how many hours went into rebuilding it and what could not be recovered at all. Keep it with the site's documentation rather than in a message. It is the document that answers the next argument about whether a backup arrangement is worth paying for, and it answers it with your own figures rather than with a general claim.