WordPress site redirecting to another site: how to tell a hack from a setting, and what to do first

Run these in a terminal on your own computer, with your own address. The first asks plainly. The second says it arrived from Google. The third says it is Chrome on an Android phone. The fourth says both. Then run them again with the address of a post or a product, which is where a visitor from search lands.

Each command prints the status code and, for a redirect, the address it leads to. It also saves the page to a file. 200 with nothing after it means the page was served. 301 or 302 followed by your own address, with https or www added, is your site's normal behavior. An address on a domain that is not yours is a positive result. So is a redirect that shows on some of the four lines and not on others.

If a line showed a redirect, repeat that request with -D -, which prints the response's headers. The Location line names the destination. A line that begins X-Redirect-By means the redirect went through WordPress's own redirect function, which adds that header and says WordPress unless a plugin puts its own name there. That points at the address settings, a plugin or the theme. With no such line, the redirect came from somewhere else: a server rule such as one in .htaccess, or PHP code that does not use WordPress's function.

Not every redirect shows in the status code. Google's guidance shows a script that reads where the visitor came from and then sends the browser elsewhere. curl runs no scripts, so that page saves with a 200. This lists every script tag in a saved page. Each address in the list should be one you can name: your own domain, your analytics, your ad network. Then open the file in a text editor and search for the words Google suggests: iframe, eval and unescape.

The redirect checker follows an address hop by hop from our server, with no cookies and nothing remembered. The hacked-site check asks for a page twice, once plainly and once as a visitor from a search result, and compares where each ends. Neither presents itself as a phone.

Enter your address on Google's site status page. It says whether the site currently contains content that Safe Browsing has determined to be dangerous.

The report shows what Google has found, with sample addresses. If your site is not in Search Console yet, add it first. Google's help says you may not be able to reproduce a warning yourself, and to rely on the report as the source of truth.

The first compares every file of WordPress itself, the main index.php included, with the checksums WordPress.org holds for your version. With --include-root it also warns about files in the main folder that are not part of WordPress. The second does the same for each plugin that came from WordPress.org. Clean runs print "Success: WordPress installation verifies against checksums." and "Success: Verified" with a count, and nothing else. Any Warning: line is a finding, even when the last line says Success: a file that was added, with no original changed, is reported as "File should not exist" and the command still ends in Success.

Neither command checks .htaccess, wp-config.php, any theme, the uploads folder or the database. A plugin that did not come from WordPress.org is skipped with a warning, and WP-CLI has no checksum command for themes. So a clean result here clears two places and leaves the rest of this list.

.htaccess is Apache's configuration file for one folder, and there can be one in any folder. List them all and open each. In a file manager, turn on hidden files first, or you will not see them. A clean one in the main folder holds the block WordPress writes between # BEGIN WordPress and # END WordPress, shown in how to fix the 403 Forbidden error, plus rules that you, your host or a plugin can account for.

Google's example of a planted rule is a RewriteCond line that tests %{HTTP_REFERER} for Google, followed by a RewriteRule that ends in another site's address and [R=301]. Look also for conditions on %{HTTP_USER_AGENT} or %{HTTP_COOKIE}, and for an ErrorDocument line that names another site. On nginx there is no .htaccess. Its rules sit in the server's own configuration, so ask your host to read it.

The checksum command has already compared index.php. A clean one is a few lines: it sets WP_USE_THEMES and loads wp-blog-header.php.

wp-config.php has no checksum, because every site's is different. Compare it with wp-config-sample.php from a fresh download of WordPress. The sample holds the database settings, eight keys and salts, the table prefix, WP_DEBUG, and closing lines that set ABSPATH and load wp-settings.php. Yours will hold more, from your host and your plugins, and each line should be one somebody can explain. The command below prints the lines to read first: an address set with WP_HOME or WP_SITEURL, any file being loaded, and code passed to eval. The line that loads wp-settings.php belongs there.

These print the two addresses WordPress is using. Both should be your own. A WP_HOME or WP_SITEURL line in wp-config.php overrides the stored value, and is what prints here when one is set. Without WP-CLI, they are the two fields under Settings, then General. If a wrong address keeps you out of the dashboard, write it down. How to change your WordPress URL shows how to get back in.

Must-use plugins are PHP files in wp-content/mu-plugins. They are always on, cannot be switched off from the dashboard, and are not in the default list on the Plugins screen. Drop-ins are files with fixed names placed straight in wp-content, such as advanced-cache.php, object-cache.php and db.php. Hosts commonly use must-use plugins, and a caching plugin may add a drop-in. A clean list is short, or empty, and every entry is one your host or a plugin of yours accounts for. Without WP-CLI, open wp-content and wp-content/mu-plugins in your host's file manager.

The list shows which theme is active and, for a child theme, which is its parent. WordPress runs the functions file of both. Open functions.php, header.php and footer.php in each theme's folder under wp-content/themes. A block theme has header.html and footer.html template parts in place of the last two.

The only clean original is a fresh copy of the same version from where the theme came, so compare against that. Without one, read for the patterns Google's guidance shows: a script tag that loads from a domain you do not know, an iframe with no height or width, a script that tests document.referrer and then sets the location, and a long unreadable string passed to eval.

This searches every text column of WordPress's tables and prints the table, the column, the row and the text around each match. Posts show under post_content. Widgets and settings show under option_value. WordPress lets administrators and editors put JavaScript in posts, pages and widgets, so a match is not a finding by itself. A clean result is no match, or matches you can name, such as an embed you pasted. Run it again for <iframe. Without WP-CLI, use the search in a database tool such as phpMyAdmin.

WordPress's documentation gives a user nobody created as a clear sign of a hack. Every name here should be a person you can account for, with their own email address. Without WP-CLI, open the Users screen and select the Administrator link above the table.

Do not delete the rule, the file or the user. The site as it stands is the record of what was done to it, and deleting the one thing you can see leaves the things you cannot. Keep your notes and the files curl saved.

The hacked site runbook has the order: have the host take the site offline for the public if it is harming visitors, take a full copy of the files and the database, then change the passwords and the secret keys. Take the copy before any cleaning.

How to remove malware from a hacked WordPress site has the steps: restore a backup from before the break-in, or replace everything that has a clean original and check the rest by hand. It also covers finding the way in.