The traffic graph looked like a ski slope in July — going the wrong direction. It took me longer than I'd like to admit to figure out why, and even longer to fix it. This is not a triumphant story about discovering a secret SEO lever. It's a story about compounding small mistakes, slow diagnosis, and the kind of incremental recovery that never feels like enough until one day it does.
I'm writing this partly to have a record of what actually happened, and partly because every SEO postmortem I've read online is either vague ("we fixed technical issues!") or written by someone selling a tool. This one is neither.
How I broke it (the short version)
I didn't break it in one dramatic moment. I broke it gradually, across several changes that each seemed fine in isolation. In rough order:
- Restructured URLs without redirects
- Added a
noindexmeta tag to a staging environment and then forgot to remove it before deploying - Consolidated several thin pages into one, killing URLs Google had already indexed
- Deployed a site with misconfigured canonical tags that pointed every page at the homepage
Any one of these would have been recoverable quickly. All four, stacked over about eight weeks with no monitoring in place, turned into a real mess.
The URL restructure without redirects
This one is embarrassing because it's the most avoidable. I changed a URL pattern — from /services/hvac-repair/ to /hvac-repair/ — to flatten the nav structure. Made sense for the site's IA. I just... didn't add 301 redirects. I told myself the pages were new anyway and didn't have much link equity.
That was wrong. They had internal links pointing at them. Other pages linked to them. And Google had already crawled and cached several of them. When those URLs returned 404, the signal was clear: this content is gone.
The fix was straightforward once I caught it — add the redirects in the Cloudflare Pages _redirects file:
/services/hvac-repair/ /hvac-repair/ 301
/services/electrical-repair/ /electrical-repair/ 301
/services/plumbing/ /plumbing/ 301But the damage was already done for a few weeks. Crawlers had already revisited those 404 pages and started dropping them from the index. Redirects help, but they don't instantly undo the signal of having returned a 404.
Lesson: URL restructures are fine. Not adding redirects is not fine. Even for "new" pages — check Search Console for whether they've been crawled before you delete the old URL.
The noindex that shipped to production
This one still stings. In the <head> of the site's layout, I had:
<meta name="robots" content="noindex, nofollow" />It was there to keep the staging environment from getting indexed while I was working on it. I had a comment next to it — <!-- REMOVE BEFORE LAUNCH --> — which I ignored. I deployed. The site ran with noindex for about three weeks before a client mentioned their site wasn't showing up for their own business name.
Three weeks of Googlebot visiting pages and being politely told to not index any of them.
The right approach, which I now use on every project, is to conditionally render the tag based on an environment variable rather than leaving a comment as the only safeguard:
---
const isProduction = import.meta.env.PROD;
---
{!isProduction && (
<meta name="robots" content="noindex, nofollow" />
)}In Astro, import.meta.env.PROD is true during a production build. This way the tag is structurally impossible to ship to production. No comment needed.
Lesson: Never use a human reminder as a safeguard for something a conditional can handle. Comments get ignored. Code doesn't.
The canonical tag disaster
This was the subtlest mistake and the hardest to diagnose. I had added canonical tags to every page — good practice — but made an error in the template. Instead of using the current page's URL, I had hardcoded the homepage URL as a fallback and never replaced it with the dynamic value.
Every page was telling Google: "The canonical version of this content is the homepage." So Google looked at 30 pages all claiming to be duplicates of the homepage, and started treating them as thin or duplicate content accordingly.
Here's the correct pattern in an Astro layout:
---
const canonicalURL = new URL(Astro.url.pathname, Astro.site);
---
<link rel="canonical" href={canonicalURL} />Astro.site comes from the site key in astro.config.mjs. Astro.url.pathname gives you the current page's path. Together they produce the correct absolute URL for every page without any hardcoding.
I didn't catch this for almost two weeks because the canonical tag rendered in the HTML and looked right visually — you have to actually check that the value is dynamic, not just that the tag is present.
Lesson: Audit your canonical tags page by page, not just by looking at the template. A curl or a View Source on three or four different pages takes two minutes and would have caught this immediately.
Diagnosing the damage: what actually told me something was wrong
I wasn't monitoring anything closely. The first signal was anecdotal — a client mentioned the site wasn't appearing for obvious searches. I opened Google Search Console (which I should have been checking weekly) and saw:
- Total indexed pages had dropped by about 60%
- Coverage report showed hundreds of pages under "Excluded" with reasons like "Crawled — currently not indexed" and "Duplicate, Google chose different canonical than user"
- A spike in the "noindex" exclusion reason around the deployment date
Search Console's Coverage and URL Inspection tools did almost all of the diagnostic work once I actually looked at them. The data had been there the whole time.
The slow recovery
After fixing all four issues, I waited. That's the part nobody talks about honestly. You fix things and then you wait, and the graph does not immediately go back up. Google needs to recrawl, reindex, and reassess. For a small-to-medium site with no particular authority, that can take weeks per fix.
What helped the recovery move faster:
- Submitting the sitemap after each round of fixes, so Googlebot would reprioritize crawling
- Using URL Inspection in Search Console to manually request indexing for the most important pages
- Adding internal links back to pages that had been orphaned during the URL restructure
- Not making any other changes while waiting — this is harder than it sounds
The noindex recovery was the fastest — within about 10 days of fixing it, indexed page counts started climbing. The canonical tag issue took longer, maybe three to four weeks before the "Google chose different canonical" errors started declining. The URL redirect situation improved steadily but never fully recovered for a few pages that had already been dropped and hadn't re-earned crawl priority.
What I do differently now
Most of the changes I made are boring and procedural, which is probably why I didn't have them before:
- Check Google Search Console every week, not just when something feels wrong
- Run a crawl with a tool like Screaming Frog before and after any significant deployment, looking specifically at canonical tags, status codes, and robots directives
- Keep a redirect log — a simple text file in the repo listing every URL change and the corresponding redirect — so nothing falls through the cracks
- Use environment-conditional logic for any tag that should only appear in non-production environments
- Test the built output with
npm run build && npm run previewand view source before deploying, not just the dev server
None of these are clever. They're just habits I didn't have.
The thing I actually learned
SEO is mostly about not actively hurting yourself. The sites that rank well aren't usually doing something exceptional — they're just not making the mistakes I made. Good content, correct technical implementation, and patience beat any tactic.
The hardest part of the recovery wasn't the technical fixes. It was sitting on my hands after making the fixes and trusting that the graph would eventually recover without me poking at it. It did, mostly. A few pages never came back to where they were. That's the part that sticks with you and makes you more careful the next time.
If your traffic graph is doing something you don't understand, open Search Console first. The answer is almost always already there, waiting for you to look.