Most articles about technical SEO describe the theory. This one describes the actual work, done on this actual site, over one specific week, with the actual reports we pulled and the actual mistakes we found along the way. If you run a website and something has quietly gone wrong with how Google treats it, this is the real process for finding out why, not the simplified version.

The short version of what happened: Talmyn changed hosting providers and removed several plugins it no longer needed, including its SEO plugin, its caching plugin, and its security plugin. Traffic and impressions in Google Search Console dropped by roughly 97 percent within days. What follows is exactly how that got diagnosed and fixed, report by report.

Why this happens more often than people admit

A hosting migration or a plugin cleanup feels like housekeeping. It rarely gets treated with the same caution as a redesign. But an SEO plugin like Rank Math or Yoast does not just add a few tags. It generates the meta description on every page, the canonical URL on archive pages, the Open Graph tags that control how a link looks when shared, and often the entire structured data layer that tells Google what kind of content it is looking at. Remove the plugin without replacing what it did, and none of that disappears cleanly. It just stops rendering, silently, with no error message anywhere.

The same applies to caching and security plugins. They can be quietly setting cache headers, blocking certain crawlers, or serving a firewall page under specific conditions. None of that shows up by looking at the site in a browser. It only shows up in the reports built specifically to catch it.

Report one: Google Search Console’s Page Indexing report

This is the starting point for a reason. It answers one question directly: out of everything on the site, how much does Google actually consider part of its index right now. The report splits pages into “Indexed” and “Not indexed,” then breaks “Not indexed” down into specific reasons, each with its own list of affected URLs.

The two reasons that mattered most here were “Discovered – currently not indexed” and “Crawled – currently not indexed.” These sound similar but mean different things. “Discovered” means Google knows the URL exists, usually from the sitemap, but has not gotten around to crawling it yet. “Crawled” means Google visited the page and specifically chose not to index it. Neither one is automatically a sign of bad content. Both can simply mean Google’s crawling budget for a site has dropped, and it is being more selective about what it bothers to fully process.

The mistake to avoid here is assuming every URL in these buckets deserves to be deleted. On this site, that list included the homepage’s own daily-refreshed digest pages, several structural pages like Contact and Privacy Policy, an entire live nomination campaign, and the single best-performing article on the whole site. None of that was low quality. It was simply waiting.

Report two: the Coverage drilldown export

The Page Indexing report gives counts. The drilldown export, available from the same section, gives the actual list of affected URLs with their last-crawled date. This is what turns a vague number into a decision-making tool. Cross-referencing that list against what each URL actually is, and how well it has performed historically, is what separates a page that is genuinely thin or duplicated from a page that is simply new or temporarily deprioritized.

Report three: the URL Inspection tool

Search Console’s coverage reports are a snapshot, often a few days old. The URL Inspection tool checks a single URL’s status live, right now, including whether it has ever been crawled, when it was last crawled, whether robots.txt allows it, and whether indexing is currently allowed. Run against a spread of pages, from the homepage to a two-day-old post to the historically best-performing article, this tool showed something the aggregate reports could not: the homepage was being crawled every single day, but a post published two days earlier had never been crawled at all, and the site’s best article had not been checked in five days. That is the actual signature of reduced crawl demand. Google has not abandoned the site. It has simply stopped following through past the front door.

Report four: the Sitemaps report

This is the one report most people skip, and it is where the single most concrete bug in this whole process was found. Checking the list of sitemaps Google has on file for the site turned up an entry submitted at some point in the past with a typo in the filename, a stray extra letter that made the URL invalid. Google had been trying and failing to download that file, silently, with zero visibility from the site owner’s side unless this specific report was checked. The correct sitemap, listing every blog post on the site, existed and worked. Google simply also had a broken duplicate sitting in its records for months.

The report also shows a submitted count against an indexed count for each sitemap file. On this site, one sitemap showed 793 URLs submitted and zero indexed. That single number is a more honest measure of the actual scale of the problem than any dashboard summary.

Report five: robots.txt, read manually, line by line

robots.txt rarely changes on its own, which is exactly why it is easy to forget to check after removing a plugin. Many SEO plugins take over robots.txt entirely, adding their own admin-editable version. Remove the plugin, and WordPress quietly falls back to its bare default, which is often much shorter and missing anything that was manually added, including allowlists for AI crawlers or specific disallow rules for search and cart parameters. The fix is not exotic. It is reading the actual live file at the actual live URL and comparing it, by eye, to what it used to say.

Report six: viewing page source directly

Not a tool exactly, but a habit. Right-click, view source, and actually read the head section of a real page. This is how it became clear that meta descriptions were missing entirely, Open Graph tags were gone, and there was no structured data on the page at all, not even a single JSON-LD script block. Every one of these had been coming from the removed SEO plugin. None of them throw an error. A page with no meta description still loads perfectly. It just performs worse in search results and shares worse on social media, invisibly, until someone actually looks.

Report seven: a third-party site audit crawl

Search Console shows how Google sees the site. A separate crawling tool, run across the whole domain, catches a different category of problem: duplicate title tags, duplicate meta descriptions, broken internal links, and pages with unusually thin content. This is also where the most important lesson of the whole process showed up.

Two categories flagged by that audit, titles considered “too long” and pages considered “too short” on word count, turned out to be false positives almost across the board. The “too long” titles were the site’s best, most deliberately descriptive headlines, the kind that read as a complete sentence rather than a keyword string. The “too short” pages were company profiles, founder bios, and reference pages that are supposed to be concise. Padding them out to satisfy a generic character count or word count threshold would have made the actual content worse to satisfy a rule that was never designed with this kind of site in mind.

The lesson is not that automated audits are useless. It is that every flag needs a human to ask what the page actually is before deciding whether the flag is a real problem. A handful of findings from that same audit were completely real: a single missing page that was linked from every single article on the site, accounting for nearly half of all flagged issues by itself, plus a handful of genuinely duplicated posts and a few pages with empty meta descriptions. Fixing those was straightforward. Padding 400 correctly-written titles would not have been.

Report eight: a mobile performance audit

Crawl budget is not only about content. Google’s own documentation is direct about this: a slow or unreliable server causes Google to deliberately crawl less, to avoid making a struggling site’s problem worse. Running a Core Web Vitals check on both desktop and mobile showed a wide gap, excellent desktop numbers next to a mobile Time to Interactive well past what is considered acceptable. Digging into what was actually loading on every single page, for every visitor, revealed two scripts adding real weight for close to zero current benefit: an analytics integration nobody was actively using, and an ad script that had no ad units on the page to justify its own weight yet. Removing both measurably improved mobile load time without touching a single line of actual content.

The checklist this process turned into

Reduced to a repeatable sequence, this is what checking a site’s technical SEO health actually looks like after any plugin removal, theme change, or hosting migration:

  • Pull the Page Indexing report and read the specific reasons behind every “not indexed” bucket, not just the total count.
  • Export the drilldown list and manually check what the affected URLs actually are before deciding anything is safe to remove.
  • Run the URL Inspection tool against a spread of pages of different ages to see the real, current crawl pattern, not a delayed snapshot.
  • Check the Sitemaps report specifically, including the submitted-versus-indexed count per file, and look for any entry that looks even slightly wrong.
  • Read robots.txt directly at its live URL and compare it against what it should say.
  • View source on a real page and check for a meta description, Open Graph tags, a canonical link, and at least one JSON-LD script block.
  • Run a full-site crawl audit for duplicate titles, duplicate descriptions, broken links, and thin content, then manually verify every flag against what the page actually is before acting on it.
  • Run a mobile and desktop performance check and look specifically at what scripts are loading on every page for every visitor, regardless of whether that visitor ever uses the feature those scripts support.

What actually gets recovered quickly, and what does not

Every technical fix in this list is something that can be done in a day. Fixing a broken sitemap entry, restoring a missing meta description, correcting robots.txt, none of that requires waiting. What does require waiting is Google’s own crawl scheduling deciding to trust the site enough to increase how often and how deeply it crawls again. Google’s own guidance on this is consistent: crawl budget adjusts gradually, over weeks, based on a sustained pattern of server reliability and content value, not a single fix. Making a large number of structural changes in a short window, even good ones, can itself look like ongoing instability to a crawler’s scheduling system. The most useful thing after a round of fixes like this is often simply to stop making large changes and let the site sit stable, publishing normally, for a few weeks before checking the reports again.

Frequently asked questions

Does “not indexed” always mean a page is low quality?
No. It can also mean Google has not gotten to it yet, especially right after a crawl-budget-affecting event like a hosting migration. Checking what the page actually is, and how it has performed historically, matters more than the label alone.

Can removing an SEO plugin break a site even if nothing looks different?
Yes. Meta descriptions, canonical tags, Open Graph tags, and structured data can all disappear from the actual HTML without any visible change to how the page looks in a browser. The only way to catch it is to check the page source or run a structured audit.

How long does crawl budget take to recover after a drop like this?
Typically weeks, not days, based on Google’s own guidance, and only after the underlying technical issues are actually fixed and the site has shown a sustained, stable pattern.

Should every flag from an automated SEO audit tool be fixed?
No. Generic thresholds for title length or word count do not account for what a specific page actually is. A concise company profile page is not the same problem as a thin, abandoned blog post, even if a generic tool flags both the same way.