My Traffic Drop After Google’s Spam Update

This is about how unreviewed translations and repetitive pages hurt my Minecraft website, and what I changed.

TL;DR: My Minecraft website (MineEnchants) lost significant Google visibility around the August 2026 spam update. I found hundreds of weak URL variations caused by unreviewed translations and material pages with nearly identical content. I reduced my sitemap to 276 URLs, limited material pages to 15 useful English pages, and applied noindex to the remaining repetitive variants. I have not seen a significant recovery yet.

Table of contents

• What happened
• Where AI entered the project
• Mistake 1: Unreviewed translations
• Mistake 2: One page for every material
• What I changed
• The actual numbers
• What I recommend checking
• What I would not recommend
• Did it recover?
• Final thoughts

What happened

This post is about what happened to my recent project, MineEnchants, during the August 2026 Google spam update.

Google recorded the update as starting on August 18, 2026, and lasting around two days and sixteen hours on its Search Status Dashboard.

My traffic dropped dramatically around the same period.

I cannot prove that this update was the only cause. Search performance can change for many reasons, and Search Console does not tell you exactly why an algorithm reduced your rankings.

There was also no manual action in Search Console.

Still, the timing pushed me to perform a much deeper review of the website. That review uncovered several real problems that I should have caught earlier.

The observations, measurements, mistakes, and decisions in this post come from my actual project (This isn't an AI post:)).

Where AI entered the project

Honestly, MineEnchants was originally a dead project.

Before using AI tools, I had completed roughly 80% of it myself. I had many .txt files containing information about enchantments, items, and categories, but the images were disorganized and I did not have enough time or motivation to finish everything.

AI helped me complete some content, review the categorization, and align the remaining data.

I was also updating the Minecraft XP calculator and adding small Minecraft games to help players remember different enchantment use cases.

The problem was not simply that AI was involved. The problem was that I allowed the website to expand faster than I could personally review it.

Mistake 1: Unreviewed translations

MineEnchants originally supported English and Spanish.

When I noticed traffic arriving from more countries, adding more locales seemed like a good idea. Technically, it was easy: add translation files, generate localized routes, and include them in the sitemap.

Eventually, I had many localized pages indexed even though I could not confidently review their translation quality.

That was my first major mistake.

A translated page is not automatically useful just because it exists. If I cannot verify its accuracy, terminology, or readability, I should not ask Google to recommend it.

I returned the indexable site to the English and Spanish versions that had received proper review.

I kept only the Japanese version of the XP calculator because that specific page already had relevant Japanese traffic and provided real functionality.

The remaining Japanese pages still work for users, but they now use noindex, follow.

Mistake 2: One page for every material

This was the larger problem.

The website generated a separate URL for every combination of item and material:

/items/by-category/weapon/sword/wooden
/items/by-category/weapon/sword/stone
/items/by-category/weapon/sword/iron
/items/by-category/weapon/sword/diamond
/items/by-category/weapon/sword/netherite

This structure looks reasonable in code. Unfortunately, most enchantment rules depend on the item type, not its material.

A wooden sword and a diamond sword differ in durability, damage, and upgrade options, but their compatible enchantments are mostly the same.

Many generated pages therefore contained almost identical text with only the material name changed.

The same pattern existed across tools and armor.

I had created many URLs without creating equally distinct reasons for those URLs to exist.

Google defines scaled content abuse as producing many pages primarily to manipulate rankings rather than help users. Its examples include generated or translated pages that add little value.

I do not know whether Google classified my website this way. I only know that my architecture created the kind of low-value repetition that the policy warns about.

What I changed

First, I consolidated duplicate default URLs.

For example, an item could previously exist at both:

/items/by-category/weapon/mace
/items/by-category/weapon/mace/default

The /default version now permanently redirects to the shorter canonical URL.

Second, I removed repetitive material variants from the XML and visual sitemaps.

Removing a URL from a sitemap does not prevent indexing by itself. Because these pages can still be reached through internal navigation, I also return noindex, follow for material variants that have not been editorially approved.

I did not block them in robots.txt, because Google must be able to crawl a page to see its noindex instruction.

Third, I kept only 15 English material pages that had evidence of specific demand and enough unique information to justify a separate page.

Examples include:

• Diamond sword enchantments
• Netherite sword enchantments
• Diamond pickaxe enchantments
• Diamond hoe enchantments
• Diamond leggings enchantments
• Netherite spear enchantments

For each retained page, I added information that actually changes with the material or answers a material-specific question:

• Durability and equipment statistics
• Java and Bedrock differences
• Conflicting enchantments
• Practical enchantment combinations
• Netherite upgrade behavior
• Material-specific combat or mining decisions
• Links to supporting Minecraft documentation

I also gave these pages unique titles and descriptions instead of inserting a material name into a shared template.

Finally, I tested the result as Googlebot. Approved pages return index, follow; excluded variants return noindex, follow.

The actual numbers

Before the cleanup, Search Console reported approximately:

• 1,100 indexed pages
• 639 URLs discovered through the submitted sitemap

After the cleanup, the generated sitemap contained 276 URLs:

• 146 English URLs
• 129 Spanish URLs
• 1 Japanese URL
• 15 approved English material-detail pages

The difference between 639 discovered URLs and the new 276-URL sitemap is 363 URLs, or approximately 56.8%.

This is not a perfect before-and-after comparison. Search Console’s discovered-page count is historical and may lag behind the current sitemap.

The important part is that the website now deliberately recommends 276 URLs instead of exposing every generated variation.

What I recommend checking

If your traffic dropped around a spam update, these checks helped me most:

1. Review every locale independently.
   
   Do not index translations merely because your framework can generate them.

2. Look for pages created from combinations.
   
   Products, locations, categories, tags, filters, and materials can generate thousands of repetitive pages.

3. Ask why each page deserves to exist.
   
   Changing a title, keyword, city, or material name is not enough.

4. Review your sitemap.
   
   It should contain the canonical URLs you genuinely want indexed.

5. Use noindex where appropriate.
   
   Removing a page from the sitemap alone does not guarantee removal from Search.

6. Consolidate duplicate URLs.
   
   Redirect exact duplicates and use consistent canonical URLs.

7. Check for manual actions.
   
   I had none, so there was no reconsideration request for me to submit.

8. Record your changes.
   
   Keep the dates, sitemap counts, indexing rules, and affected page groups.

What I would not recommend

Do not delete hundreds of pages blindly.

If repetitive pages still help users navigate your website, you can keep them accessible without asking search engines to index them. Using noindex may be safer than deleting useful pages or breaking existing links.

Do not use Google’s temporary removal tool as a general recovery method either. Use it only when a page must disappear from Search urgently.

If you are going to generate 100 pages per day, make sure every page has a real purpose and provides distinct value. Publishing quickly is not automatically spam, but publishing hundreds of nearly identical pages can become a serious quality problem.

Finally, do not treat your sitemap as a Google trust score. Reducing its size will not directly restore rankings. Your sitemap should simply provide a clean list of the canonical pages you genuinely believe deserve to appear in Search.

Did it recover?

Not yet.

I have not seen a significant improvement in traffic or Search Console performance since making these changes.

That is frustrating, but it is still too early to call the work unsuccessful. Google’s spam update documentation says its automated systems may need months to learn that a website complies with its policies.

There is also no guarantee that rankings will return to their previous level. Some pages may never recover, especially if their earlier visibility depended on weak or repetitive content.

For now, I am monitoring:

• Indexed-page counts
• Crawled-but-not-indexed URLs
• Impressions by page group
• Queries for the 15 retained material pages
• Whether old repetitive URLs disappear from Search
• Whether the English and Spanish core pages regain visibility

Final thoughts

My biggest lesson is simple:

Being able to generate a page is not the same as having a reason to index it.

AI was useful for finishing the project, organizing information, and reviewing code. But automation made it too easy to expand the website beyond what I had personally validated.

The fix was not to remove everything created with AI. Google’s policy focuses on purpose and value, regardless of how the content was produced. The fix was to become much stricter about which URLs deserve search visibility.

If you have recovered from a similar Google update, I would genuinely like to hear what you changed and how long the recovery took. And if you play Minecraft, feedback about MineEnchants would be especially helpful.