{"id":4327,"date":"2026-09-08T11:03:38","date_gmt":"2026-09-08T10:03:38","guid":{"rendered":"https:\/\/voronov.solutions\/?p=4327"},"modified":"2026-09-08T11:03:38","modified_gmt":"2026-09-08T10:03:38","slug":"how-to-recover-a-website-after-a-hack-and-get-back-seo-position-using-the-external-protocol-for-wordpress","status":"publish","type":"post","link":"https:\/\/v2.voronov.uk\/en\/blog\/yak-vidnovyty-sait-pislia-zlamu-ta-povernuty-seo-pozytsii-ekstrenyi-protokol-dii-dlia-wordpress\/","title":{"rendered":"How to Recover a Hacked Website and Restore SEO Rankings: Emergency Action Plan for WordPress"},"content":{"rendered":"

Successful website recovery after hacking<\/strong> requires a systematic approach: urgent isolation of the resource with HTTP 503 status, verification of file structure integrity using checksums, deep database cleaning from backdoors, and correct configuration of server responses (HTTP 410\/404) to remove junk URLs from the index. Attempting to blindly restore an outdated backup without auditing often returns the site to the same vulnerable state due to preserved malicious code.<\/p>\n

Symptoms of Compromise: Express Diagnosis of WordPress Infection<\/h2>\n
\"Symptoms<\/figure>\n

A significant portion of WordPress and WooCommerce-based web resource hacks remain unnoticed by owners until traffic drops or search engine sanctions appear. Early identification of symptoms allows you to determine the attack vector and localize the damage.<\/p>\n\n\n\n\n\n\n\n\n
External manifestation<\/th>\nType of attack \/ Attack vector<\/th>\nImplications for SEO and business<\/th>\n<\/tr>\n<\/thead>\n
Red screen or blank screen \u00ab"Deceptive site ahead"\u00bb<\/em> in the browser<\/td>\nPhishing pages, malicious redirects, blocking by Google Safe Browsing<\/td>\nInstant blocking of all organic and direct traffic, loss of customer trust<\/td>\n<\/tr>\n
Japanese characters or pharmaceutical drug names in Google search results<\/td>\nSEO spam on the website<\/strong> (Japanese Keyword Hack \/ Pharma Hack)<\/td>\nClogging the index with thousands of generated pages, blurring relevance and pessimizing the site<\/td>\n<\/tr>\n
Redirects mobile users to third-party casino or lottery sites<\/td>\nFile injections .htaccess<\/code>, index.php<\/code> or active theme scripts<\/td>\nBehavioral sanctions from search engines, sharp increase in bounce rate<\/td>\n<\/tr>\n
Appearance of unknown administrator accounts or suspicious cron jobs<\/td>\nImplementation of web shells, backdoors, compromise of authorization keys<\/td>\nPermanent hidden access of hackers to files and databases even after removal of visible viruses<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Diagnostic matrix: restore from backup or manual cleaning<\/h2>\n
\"Diagnostic<\/figure>\n

It is important to choose the right strategy before starting work. Restoring from a backup is not always a quick solution to the problem if the copy has already been infected.<\/p>\n\n\n\n\n\n\n\n
Scenario \/ Conditions<\/th>\nRecommended action<\/th>\nCritical risks<\/th>\n<\/tr>\n<\/thead>\n
The exact time of the intrusion is known, there is a verified "clean" backup created before the date of the incident<\/td>\nRestoring files and databases from backup followed by mandatory update of all components<\/td>\nLoss of online store orders or new articles created between the time the copy was created and the time of the breach<\/td>\n<\/tr>\n
The date of the initial breach is unknown or the backups already contain malicious code<\/td>\nComplete replacement of the kernel and plugins with the original distributions + manual audit of the database and uploads folder<\/td>\nRequires more technical time, but guarantees complete removal of hidden web shells<\/td>\n<\/tr>\n
Over 30% of file structure modified, system database tables corrupted<\/td>\nThreat isolation, system directory deletion (wp-admin<\/code>, wp-includes<\/code>), deep database disinfection<\/td>\nHigh probability of re-infection without changing authorization keys and closing the vulnerability<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Emergency Protocol: 5 Steps to Site Isolation and Cleanup<\/h2>\n

Incompetent actions during the elimination of the consequences of the attack can lead to the complete loss of the database or prolonged unavailability of the resource. If you plan to perform the process yourself, follow a strict sequence of actions. We also recommend that you read the guide on steps to safely remove viruses from a website<\/a> before starting to modify system files.<\/p>\n

Step 1. Temporary isolation (Maintenance Mode)<\/h3>\n

If a resource generates malicious redirects or phishing content, it must be immediately closed to external visitors by configuring the server to return a status code. HTTP 503 (Service Unavailable)<\/strong>. This lets Google crawlers know that the site is temporarily under maintenance, preventing the original pages from falling out of the index during the cleanup.<\/p>\n

Step 2. Change secret keys (SALT) and reset authorization<\/h3>\n

To block sessions of attackers who could intercept the administrator cookie, generate a new set of secret keys in the configuration file wp-config.php<\/code>. According to the documentation WordPress Hardening Documentation<\/a>, update constants AUTH_KEY<\/code>, SECURE_AUTH_KEY<\/code>, LOGGED_IN_KEY<\/code> and NONCE_KEY<\/code> forcibly terminates all active user sessions in the system.<\/p>\n

Step 3. Verifying the integrity of core and plugins via WP-CLI<\/h3>\n

Instead of manually searching for modified sections of PHP code, use the WP-CLI console utility to compare the checksums of local files with the reference data in the official WordPress.org repository:<\/p>\n

# Verify the integrity of the WordPress core wp core verify-checksums # Verify the integrity of all installed plugins wp plugin verify-checksums --all<\/code><\/pre>\n
According to the documentation WP-CLI Command Reference<\/a>, the utility points to the exact files where code was added or changed. Directories wp-admin<\/code> and wp-includes<\/code> The safest thing to do is to completely remove and replace with fresh files of the corresponding kernel version.<\/p>\n
Step 4. Cleaning the database, backdoors, and WP-Cron<\/h3>\n
Malicious scripts often become embedded within the database or through system task schedulers, causing recurrent infections:<\/p>\n