> [!NOTE]
> **Note:** Unsure if your site is hacked? Start by reading the guide on [how to check if your site is hacked](https://web.dev/articles/how-do-i-know-if-my-site-was-hacked.md.txt).

This guide is for a type of hack that creates autogenerated Japanese text
on your site, which we refer to as the Japanese keyword hack. It's
designed for users of popular [content management systems
(CMSs)](https://wikipedia.org/wiki/Web_content_management_system#Notable_web_CMS),
but you'll still find this guide useful if your site doesn't use a CMS.

## Identify this type of hack

The Japanese keyword hack typically creates new pages with autogenerated
Japanese text on your site in randomly generated directory names
(for example, `http://example.com/ltjmnjp/341.html`). These pages are
monetized using affiliate links to stores selling fake brand merchandise
and then shown in Google Search. Here is an example of what one of these
pages looks like:
![An example of a page with the Japanese keyword hack.](https://web.dev/static/articles/fix-the-japanese-keyword-hack/image/an-example-a-page-the-j-d604733ae783f.png) A page of text generated by the Japanese keyword hack.

With this type of hack, the hacker will typically add themselves as a property
owner in Search Console, to increase profits by manipulating your site's
settings like geotargeting or sitemaps.
If you've received a notification that someone you don't know has
verified your site in [Google Search
Console](https://www.google.com/webmasters/tools/), there's a strong
possibility that your site has been hacked.

Start by checking the
[Security Issues](https://www.google.com/webmasters/tools/security-issues)
tool in Search Console to see if Google has discovered any of these hacked pages
on your site. Sometimes you can also uncover pages like this by opening a Google
Search window and typing `site:_your site url_`, with the root level URL of
your site. This will show you the pages that Google has indexed for your site,
including the hacked pages. Flip through a couple of pages of search results to
see if you spot any unusual URLs. If you don't see any hacked content in Google
Search, use the same search terms with a different search engine. Here's an
example of what that would look like:
![An example of a hacked site in search.](https://web.dev/static/articles/fix-the-japanese-keyword-hack/image/an-example-a-hacked-site-02881033c49c4.png) The hacked pages show up in Google Search results.

> [!NOTE]
> **Note:** You'll notice that the search results here contain many pages created by someone other than the site owner. If you look closely at the descriptions, you'll see examples of the gibberish text this hack creates.

Typically, when you click a link to a hacked page, you'll either be
redirected to another site, or see a page full of gibberish content. However,
you might also see a message suggesting that the page doesn't exist (for
example, a 404 error). Don't be fooled! Hackers will try to trick you into
thinking the page is gone or fixed when it's still hacked. They do this by
[cloaking](https://support.google.com/webmasters/answer/66355)
content. Check for cloaking by entering your site's URLs in the
[URL Inspection tool](https://support.google.com/webmasters/answer/9012289). This tool lets
you see the underlying hidden content.

If you see these issues, your site has most likely been affected by this type of
hack.

## Fix the hack

Before you start, make an offline copy of any files before you remove them, in
case you need to restore them later. Better yet, back up your entire site before
you start the cleanup process. You can do this by saving all the files that are
on your server to a location off your server or searching for the best backup
options for your particular Content Management System (CMS). If you're using a
CMS, also back up the database.

### Remove newly created accounts from Search Console

If a new owner you don't recognize has been added to your Search Console
account, revoke their access as soon as possible. You can check which users
are verified for your site on the
[Search Console verification page](https://search.google.com/search-console/about).
Click "Verification Details" for the site to view all verified users.

To remove an owner from Search Console, refer to the Remove Owner
section of the
[Managing users, owners, and permissions Help Center](https://support.google.com/webmasters/answer/2453966).
You'll need to remove the associated verification token which is typically
either an HTML file on the root of your site or a dynamically generated
`.htaccess` file mimicking an HTML file.

If you can't find an HTML verification token on your site, check for a rewrite
rule in your `.htaccess` file. The rewrite rule will look similar to this:

    RewriteEngine On
    RewriteRule ^google(.*)\.html$ dir/file.php?google=$1 [L]

> [!NOTE]
> You can typically check if you've successfully removed a dynamically generated verification token by navigating to a simulated verification token file like `wwww.example.com/google[random number and letters].html`. For example, if your site is www.brandonsbaseballcards.com, try navigating to www.brandonsbaseballcards.com/google1234.html. If that page returns a HTTP 404, then the dynamically generated verification token is likely fixed.

To remove the dynamically generated verification token from your `.htaccess`
file, follow these steps:

### Check your `.htaccess` file (2 steps)

Aside from using a `.htaccess` file to create dynamically generated verification
tokens, hackers often use `.htaccess` rules to redirect users or create
gibberish spammy pages. Unless you have custom `.htaccess` rules, consider
replacing your `.htaccess` with a completely new copy.

#### Step 1

Locate your `.htaccess` file on your site. If you're not sure where to find it
and you're using a CMS like WordPress, Joomla, or Drupal, search for
".htaccess file location" in a search engine along with the name of your CMS.
Depending on your site, you might see multiple `.htaccess` files.
Make a list of all of `.htaccess` file locations.

> [!NOTE]
> **Note:** The `.htaccess` is often a hidden file. Allow showing hidden files when searching for it.

#### Step 2

Replace all `.htaccess` files with a clean or default version of the `.htaccess`
file. You can usually find a default version of a `.htaccess` file by searching
for "default `.htaccess` file" and the name of your CMS. For sites with multiple
`.htaccess` files, find a clean version of each one and replace them.

If no default `.htaccess` exists and you've never configured an `.htaccess`
file on your site, the `.htaccess` file you find on your site is probably
malicious. Save a copy of the `.htaccess` file(s) offline just in case and
delete the `.htaccess` file from your site.

### Remove all malicious files and scripts (4 steps)

Identifying malicious files can be tricky and time-consuming. Take your
time when checking your files. If you haven't yet, this is a good time to back
up the files on your site. Do a Google Search for "back up site" and the name of
your CMS to find instructions on how to back up your site.

#### Step 1

If you use a CMS, reinstall all the core (default) files that come in the
default distribution of your CMS, as well as anything you've added (such as
themes, modules, or plugins). This helps ensure that these files are clear of
hacked content. You can do a Google Search for "reinstall" and your CMS name to
find re-installation instructions. If you have any plugins, modules, extensions,
or themes, make sure to reinstall those as well.

> [!CAUTION]
> **Caution:** Reinstalling your core files may cause you to lose any customizations you've made. Always create a backup of your database and all files before you reinstall.

#### Step 2

Hackers often modify your sitemap or add new sitemaps to get their
URLs indexed more quickly. If you previously had a sitemap file, check the
file for any suspicious links and remove them. If there are any sitemap files
you don't remember adding to your site, review the file. Remove the file if it contains only spammy URLs.

#### Step 3

Look for any other malicious or compromised files. You might have already
removed all malicious files in the previous two steps, but it's best to work
through these next few steps in case there are more files on your site that have
been compromised.

Don't get overwhelmed by thinking that you need to open and look through every
PHP file. Start by creating a list of suspicious PHP files that you want to
investigate. Here are a few ways to determine which PHP files are suspicious:

- If you've already reloaded your CMS files, look only at files that aren't part of your default CMS files or folders. This should rule out a lot of PHP files and leave you with a handful of files to look at.
- Sort the files on your site by the date they were last modified. Look for files that were modified within a few months of the time that you first discovered your site was hacked.
- Sort the files on your site by size. Look for any unusually large files.

> [!NOTE]
> **Note:** Attackers commonly inject scripts into the following files: `index.php`, `wp-load.php`, `404.php`, and `view.php`.

#### Step 4

Once you have a list of suspicious PHP files, check them for malicious content.
If you're unfamiliar with PHP, this process might be more time consuming,
so consider brushing up on some [PHP documentation](https://php.net/docs.php).
If you're completely new to coding, we recommend speaking with an experienced
developer. In the meantime, there are some basic patterns that you can look for
to identify malicious files.

If you use a CMS, and aren't in the habit of editing its PHP files directly,
compare the files on your server to a list of the default files packaged with
the CMS and any plugins and themes. Look for files that don't belong, as well as
files that are larger than their default version.

Scan through the suspicious files you've already identified to look for blocks
of obfuscated code. This might look like a combination of seemingly jumbled
letters and numbers, usually preceded by a combination of PHP functions like
`base64_decode`, `rot13`, `eval`, `strrev`, or `gzinflate`. Here's an example of
what the block of code might look like. Sometimes all this code will be stuffed
into one long line of text, making it look smaller than it actually is.

    $O_O0O_O0_0=urldecode("%6E1%7A%62%2F%6D%615%5C%76%740%6928%2D%70
    %78%75%71%79%2A6%6C%72%6B%64%679%5F%65%68%63%73%77%6F4%2B%6637%6A");
    $OO0_0OO0__=$O_O0O_O0_0{26}.$O_O0O_O0_0{6}.$O_O0O_O0_0{10}.$O_O0O_O0_0{30}

### Check whether your site is clean

Once you're done getting rid of hacked files, check to see if your hard work
paid off. Remember those gibberish pages you identified earlier? Use the Fetch
as Google tool on them again to see if they still exist.

If they respond as "Not Found" in Fetch as Google, chances are you're in pretty
good shape and you can move on to fixing the vulnerabilities on your site.

## How do I prevent getting hacked again?

Fixing vulnerabilities on your site is an essential final step for fixing your
site. A recent study found that 20% of hacked sites are hacked again within
one day. Knowing exactly how your site was hacked is helpful. Read our
[top ways websites get hacked by spammers](https://web.dev/articles/top-ways-sites-get-hacked-by-spammers.md.txt)
guide to start your investigation. If you're unable to figure out how your site was hacked,
follow this checklist to reduce vulnerabilities on your site.

- **Regularly scan your computer**: Use popular antivirus software to check for viruses or vulnerabilities.
- **Regularly change your passwords**: Regularly changing the passwords to all your website accounts like your hosting provider, FTP, and CMS can prevent unauthorized access to your site. It's important to create a strong, unique password for each account.
- **Use [2-Step Authentication (2FA)](https://wikipedia.org/wiki/Two-factor_authentication)**: Consider enabling 2FA on any service that requires you to sign in. This makes it harder for hackers to sign in even if they successfully steal your password.
- **Update your CMS, plugins, extensions, and modules regularly**: Hopefully you've already done this step. Many sites get hacked because they're running outdated software. Some CMSs support auto-updating.
- **Consider subscribing to a security service to monitor your site**: Many services are available that can help you monitor your site for a small fee. Consider registering with them to keep your site safe.

## Additional resources

If you're still having trouble fixing your site, there are a few more
resources that might help you.

These tools scan your site and may be able to find problematic content.
Other than VirusTotal, Google doesn't run or support them.

- [Virus Total](https://www.virustotal.com/)
- [Sucuri Site Check](https://sitecheck.sucuri.net/)
- [Quttera](http://www.quttera.com/)

These are just some tools that may be able to scan your site for problematic
content. Keep in mind that these scanners can't guarantee that they will
identify every type of problematic content.

Here are additional resources from Google that can help you:

- [Google Search Central Help Community](https://support.google.com/webmasters/community)
- [Google SafeBrowsing](https://safebrowsing.google.com/)