WordPress asks to install again: recover the existing site

Stop the wizard and recognize the scenario

You open the administration area of a WordPress site that was publishing yesterday. The browser sends you to /wp-admin/install.php and offers a language or new site title. A few minutes later, the same address says WordPress is already installed. The wizard does not know which content you intended to recover. It examines only what the instance currently starting can identify. Submitting the form would authorize installation, while the problem may be limited to the database or path that instance is looking at.

Close the tab offering to complete installation. Keep a screenshot focused on the message and address, without private parameters. Record the time and time zone. Open the normal site address, then its login address, without clicking the installation form. In developer tools' Network tab, retain redirects and identify which response sent you to the wizard. A redirect from the homepage has a different starting point from directly opening install.php through an old bookmark.

Distinguish the operational site from the copy being prepared for its first installation. For a site with content, the priority is to find the instance containing it. For a new disposable environment, an “Already Installed” screen may mean you simply reopened the wizard after successful installation or it points to an old set of tables. Verify site identity before choosing. A login screen showing another address or title does not validate creation of your new site.

• Known site sent to the wizard: do not submit the form or delete any table. Retain the time, path and symptom.
• New environment displaying “Already Installed”: first check the folder, database and prefix; another WordPress installation may use the target.
• Explicit message about an inaccessible table or connection error: retain its wording separately. It represents a different stopping point.

Understand what WordPress checks during startup

WordPress core can recognize an installation from its cache, then from the siteurl option in the instance's options table. If the value is missing, it also examines expected tables. Some combinations of present but unreadable tables lead to a database-repair message instead of the wizard. It is therefore insufficient to say “the wizard appears, so the database is empty” or “Already Installed proves all tables are healthy”. Both messages are decisions made during a particular request.

For a single site, startup may redirect to the wizard when it does not recognize an installation. The wizard then checks again and may respond “Already Installed”. Different results between these requests guide investigation: configuration loaded on different nodes, intermittent reads, persistent cache, a cached redirect or a confused copy environment. They do not distinguish these causes without further evidence. Multisite follows a different branch; if you see a network-specific installation error, retain the subsite context and have the network checked instead of applying a single-site prefix correction.

Also check who sent the redirect. A response containing Location pointing to the wizard may come from a server rule, cache or mechanism that never started WordPress. WordPress and proxy redirects look similar in the address bar. The first HTTP code, available headers, origin trace and time are more useful than the destination screen alone. If the origin response is normal but the redirect exists only at the edge, do not change tables.

Route 1: find the folder and database used by the domain

This method suits cases following migration, copying or addition of a second site. In the hosting panel, open the domain's record and locate the document root actually configured. Compare it with the folder containing your site's files. A name such as public_html or a recent archive does not prove that the domain uses them. If deployment configuration changed, compare with the working instance's record and corresponding backup.

In the file manager or through SFTP, inspect the wp-config.php actually used by this instance. It is generally in the WordPress root; WordPress can also load it from the parent directory in certain layouts. Some configurations read environment variables or an included file: the value written in a configuration template is not always the effective value. For your own checks, record the database name, host and $table_prefix. Do not transmit the file or DB_PASSWORD value. Across multiple nodes, compare their configuration references through the hosting owner.

The prefix is added before table names. With wp_, the options table is normally wp_options. With atelier_, WordPress normally looks at atelier_options. In a shared database, several sets may be valid. A set containing an options table and posts table is not necessarily the domain's set. Check siteurl, backup context and, on a copy, known content before changing the target.

1. Compare the domain, installation path and database references with the hosting record. On the copy, keep a dated private configuration version and the current document root.
2. In the database panel, select the recorded database, then use the read-only queries in the next two sections. Check the account and connection that performed the read; an administration account may see tables the WordPress account cannot read.
3. If a folder, database or prefix error is confirmed, correct only that erroneous reference on a copy. Restore the value established by the previous configuration or site inventory. Do not rename a site's tables to fit an uncertain configuration.
4. Reopen the homepage and usual login. You should recover known content and the correct instance's administration area without the wizard. If the result does not match, restore only the changed reference and retain the new response record.

Identify visible tables without modifying them

In phpMyAdmin, select the database in the left column, then the SQL tab. In a MySQL or MariaDB client, explicitly select that database when connecting. First run only the first SELECT: the returned name must match the expected target. If the result is empty or identifies another database, stop and reselect the correct one. Then replace the three example names with the site's names. Retain the options, posts and users suffixes for the single site described here. If the project uses a custom user table, verify its name with the maintainer instead of treating its absence as proof.

The second read gives a sample of visible tables. It changes neither rows nor structure. A missing table may indicate a wrong prefix, an account with different permissions or an incomplete restore. If the panel account sees the set but WordPress cannot read it, ask the owner to test the same operations with the site's database identity in a private terminal. Avoid copying a secret into the command line. The error obtained with the exact account can distinguish access denial from an actually missing table.

SELECT DATABASE() AS base_active;

SELECT TABLE_NAME
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = DATABASE()
  AND TABLE_NAME IN ('wp_options', 'wp_posts', 'wp_users')
ORDER BY TABLE_NAME;

Confirm which installation owns these options

Only after confirming the database and table name, read the two options below. Replace wp_options with the exact identified name and retain the backticks around the SQL identifier. This query retrieves no user row or complete configuration. Nevertheless, treat staging URLs as internal information. If siteurl is present and nonempty, this reading is consistent with an installation recognized by core in the context where you read the table. It does not demonstrate that every WordPress node accesses this table or that other data is intact.

siteurl identifies the WordPress installation address and home the site address; they can legitimately differ when WordPress resides in a subdirectory. Constants or filters may also alter values used at runtime. Compare this result with the intended deployment and a known backup. Do not randomly replace both URLs with an identical value. If the value resembles the same site's old address, check whether you are looking at the correct migrated content before concluding that the table belongs to another project.

SELECT option_name, option_value
FROM `wp_options`
WHERE option_name IN ('siteurl', 'home')
ORDER BY option_name;

Route 2: recover an expected but incomplete or unreadable database

If the domain, folder, database and prefix agree, focus on tables and their permissions. A successful SQL connection does not mean the account can read the options table. If the table exists but the WordPress account is denied reading, have its current permissions compared with those intended for this database alone. On managed hosting, give support the time and error type without sending secrets through a public channel. Do not broaden permissions to every database on the server to pass the test.

If a table is missing, reading fails for a storage reason or siteurl is missing when the site should contain content, find a consistent backup. Check its date and expected table set. A partial export may contain posts without necessary options or relationships. Do not create an empty table to clear the error; it would recover neither correct settings nor content consistency. A table-repair function does not recreate a missing backup. A message suggesting repair is insufficient reason to choose it.

1. On an isolated copy, import the validated backup into a new database reserved for testing. Do not import the export into a database still serving the old site.
2. Point the copy to this database while retaining a private version of its original configuration. If the copy's site address must differ, apply the planned migration procedure for that copy and record changes.
3. Reread tables and options, then open known content and the administration area with an account intended for the copy. Check a date or content version so you do not confuse a working backup with a sufficiently recent one.
4. To cancel the test, restore the copy's initial database reference. Keep both databases separate and retain the records. Delete nothing until the data owner validates recovery.

Route 3: isolate an intermittent redirect

This route helps when the wizard appears and disappears without your changes. Collect several observations of the homepage and login page. Record the time, first response code, destination and browser context. Retain any request identifier. With the host, compare proxy, server and database logs over the same period. A later SQL check when everything works cannot rule out a fault at the recorded time.

Ask the owner to establish whether failing requests reach the same node and use the same database, prefix and object-cache references. If a redirect never reaches WordPress, examine the layer serving it: page cache, hosting rule or old redirect. If the response comes from WordPress, compare access to options, then object cache or early-loaded components, including a custom database connection file. Installation checking occurs before ordinary plugins load during standard startup; deactivating all plugins is not a first test that locates this branch.

1. On a representative copy, reproduce the difference between the two paths or nodes. Change only one confirmed reference or rule at a time.
2. If a redirect rule or cached response is responsible, correct the rule, then remove the cached response for affected paths. If nodes have different configurations, align the established configuration before repeating requests.
3. Check the homepage, login and a deep link several times, in a private window and through normal navigation. One successful load is insufficient when the symptom was intermittent.
4. Keep the previous rule or version for rollback. If it reproduces the wizard on the copy, do not restore it on the live site merely to obtain further proof.

Complete only an installation intended to be new

If the environment is truly new, confirm that it hosts nothing to recover. Prefer assigning a dedicated empty database and its intended configuration on the correct working domain. This separation makes diagnosis easier than adding a new prefix to a database used by a team site. If installation already completed and checks identify the correct site, resume at the login page: reopening the wizard is not necessary.

Testing is complete when normal requests no longer lead to the wizard and you recover the correct site's content or, for a truly new installation, login leads to the expected new administration area. Retain the mapping between domain, folder, database and prefix with check times. This record lets you verify the same point after a move or server change without exposing the full configuration.

Fill in the domain, folder, database and prefix mapping

To make comparison usable, keep a private record of four values. Entirely fictional example: domain atelier.example, root /srv/sites/atelier/public, database atelier_prod, prefix bpc_. In this case, reading must target bpc_options, not wp_options. Alongside, record the value actually observed on the server and the source of the expected value, such as a retained deployment configuration.

If the root matches the domain but wp-config.php names atelier_test, the difference to check is the database; it does not justify renaming tables. If the database is correct but the prefix is wp_ while the confirmed set is bpc_, the prefix is the lead. If everything agrees and only one request fails, add the time and responding node: the problem may be intermittent.

Never include the password in this record. No free or paid plugin can repair an incorrect target before WordPress recognizes its installation. The hosting panel, established configuration and targeted SQL reads are the appropriate tools. After correction, check known recent content, not merely the appearance of the login screen.