Traffic Dropped After a WordPress Update: Seven Things Plugins Break

This is the category of drop I most enjoy finding, because it is real, it is provable, and it is fixable this week rather than next quarter. It is also the one most often misattributed, because WordPress updates happen quietly and automatically and nobody writes them down.

The first question is not what Google did. It is what changed on your site, and the answer is usually sitting in an update log nobody has looked at.

How do I find what changed and when?

Start with the dates rather than the symptoms, because if nothing changed near your break date this whole page is the wrong diagnosis.

1. Establish the break date from daily Search Console data rather than the date you noticed.
2. In WordPress, open Dashboard then Updates, and check what was updated recently. Many hosts also keep an update log with timestamps.
3. Check your host’s deployment or backup history, which often records exactly when files changed.
4. Ask whoever else has admin access. Auto-updates and a colleague’s Tuesday afternoon both count as changes.
5. Line the two lists up. A plugin update two days before a break date is a strong lead.

Two days rather than same-day, usually. Google has to recrawl before a change affects anything, so the ranking effect trails the deploy by anything from a day to a fortnight depending on how often your site is crawled.

What can a plugin update actually break?

More than most people expect, and almost all of it invisible from the front end.

What breaks	Usual culprit	Measurement (how to check)
Noindex applied to a post type	SEO plugin settings reset on update	View source on each template; check plugin post-type settings
Canonical tags pointing at the wrong URL	SEO plugin, or two plugins both writing canonicals	URL Inspection: compare declared against selected
Robots.txt rewritten	Security or caching plugin	Visit /robots.txt directly
URL structure changed	Permalink or redirect plugin	Test old URLs for 404s
Schema removed or duplicated	Theme update, or plugin overlap	Rich Results Test on a key page
Content now rendered by JavaScript	Page builder or theme update	Read the rendered HTML in URL Inspection
CSS and JS blocked from crawling	Security or optimisation plugin	Check robots.txt for wp-content or wp-includes blocks

The second row causes trouble out of proportion to how boring it sounds. Two plugins both writing canonical tags produces conflicting or duplicated declarations, and Google resolves that by ignoring you and choosing for itself.

How do I compare against a working version?

You need to know what your pages looked like before, which is why the Wayback Machine is the most useful tool in this diagnosis.

Pull an archived copy of two or three important pages from a date before the decline. Then compare the head section of that HTML against your live one. You are looking for the robots meta tag, the canonical, the title, and whether the body content is present in the source or arrives later.

If you keep backups, a staging restore is better still, because you can diff the actual template files rather than the output. Most hosts keep thirty days, which is usually enough if you catch this reasonably quickly.

Why does this look like an algorithm update?

Because the shape is similar enough to fool people, and because confirmed updates run often enough that one is usually available to blame.

The tell is in the indexing data rather than the traffic graph. A quality reassessment leaves your pages indexed and lowers where they rank. A technical fault usually shows up in the Pages report: excluded URLs rising, a new exclusion reason appearing, or indexed counts falling. That difference is visible within days and it settles the question.

Scope helps too. Plugin faults tend to hit one template or post type, because that is how WordPress applies settings. A core update reassesses the whole site. If your products are fine and your blog vanished, that is a template-level cause, not a judgement about your content.

The page scope analyzer will tell you whether the loss is confined to a section, and Google deindexed my pages covers what each exclusion reason means.

This is not a WordPress fault if

• Nothing was updated near the break date. Check the log before building a theory around it.
• Indexed counts are stable and positions fell evenly across every template. That is a site-wide reassessment.
• Impressions held and only clicks fell. Nothing was demoted. That is displacement.
• Your head tags match the archived version exactly. Then the output did not change, whatever was updated.

How do I stop it happening again?

Three habits, none of them expensive, and together they turn this from a mystery into a five-minute check.

Turn off automatic updates for your SEO plugin, caching plugin and theme, and update those deliberately instead. Those three touch output that Google reads, and they are the ones worth watching go in.

After any significant update, check four things on one page from each template: the robots meta tag, the canonical, the title, and whether the body copy is in the source. That is genuinely a five-minute job and it catches almost everything in the table above.

And keep a written record of what changed and when. It costs nothing and it is the difference between diagnosing a drop in an afternoon and guessing at it for a month. This is the same discipline that prevents a fix undoing itself later, covered in my site recovered then dropped again.

How long does recovery take once it is fixed?

One to four weeks, because recovery follows recrawling rather than any reassessment cycle. This is the good news about technical causes and it is why ruling them out first matters so much.

Requesting indexing on your most important affected URLs speeds it up, and resubmitting your sitemap helps Google find the rest. If the fault removed pages from the index entirely, expect the slower end of that range, since the pages have to be rediscovered as well as recrawled.