We help businesses get found. So it was a special kind of humbling to realise that for a stretch, our own site was quietly working against itself in Google. No dramatic outage. Just a slow, invisible drag, the worst kind, because nothing looks broken. This is the build log of finding and fixing it.
I am writing it down for the same reason I write all of these: the mistakes teach more than the wins, and someone building their first site will make at least one of these.
Bug one: the same FAQ on every single page
Early on I added FAQ structured data to the home page. Structured data is the hidden markup that lets Google show rich results, the little expandable questions under a search listing. Good idea. Bad implementation. The FAQ schema was mounted in a shared layout, which meant every route on the site, every blog post, every product page, shipped with the home page's FAQ attached to it.
To a search engine that reads as one thing: this site says the same five questions answer every page. It muddies what each page is actually about. I found it by doing the thing I should have done first, opening the rendered source of a few different pages and reading the schema, not just trusting that it looked fine in the browser. The fix was to strip the global FAQ and let each page carry only the structured data that belongs to it. Blog posts now carry article markup and their own topic-specific questions, nothing borrowed from the home page.
Bug two: the redirect that ate our rankings
This one was more expensive. We had a redirect that sent visitors to a regional version of a page based on where they were coming from. Helpful for humans. Quietly harmful for the Google crawler, which does not browse from one fixed place, and which can read an aggressive automatic redirect as the original page no longer being the real one.
The symptom was pages slipping in the rankings for no reason I could see in the content. The cause was infrastructure, not words. I only caught it by separating two questions I had been treating as one: "is the content good" and "can the crawler actually reach and trust the content". They are not the same question, and I had spent days on the first when the problem lived in the second.
Bug three: trusting the browser instead of the tools
The meta-lesson underneath both bugs is the same. A site can look perfect to you and be misread by a machine, because you and the crawler are not looking at the same thing. You see the finished, rendered page. The crawler sees the raw response, the redirects, the headers, the markup. For weeks I had been checking my work by looking at the site. Of course it looked fine. I was the least reliable tester of whether it was findable.
What changed is that I stopped reviewing SEO by eye and started reviewing it the way the crawler does: reading raw source, checking every redirect, validating structured data, watching the sitemap. Boring, mechanical, and the only way to see what I could not.
What I actually changed
- One page, one purpose, one set of structured data. No shared schema leaking across routes.
- No automatic redirects that hide the canonical page from a crawler. Humans get a choice, the crawler gets a straight answer.
- Review with tools, not eyes. Raw source, redirect chains, schema validators, sitemap. If a machine has to find it, check it the way a machine would.
None of this is clever. It is the unglamorous hygiene that every site needs and most skip because the site looks fine. It looked fine to me too. That was the whole problem.
It rhymes with a bigger lesson I keep relearning: measure the thing honestly before you trust it. It is the same instinct that made me audit my own business and not like the numbers. Look at what is real, not at what you hope is real.
Frequently asked questions
What is structured data and why did it matter here? Structured data is hidden markup that tells search engines what a page is about. Ours was misconfigured so that one page's FAQ was attached to every page, which blurred what each page actually covered. Fixing it meant giving each page only the markup that belongs to it.
Why can a redirect hurt SEO? An automatic redirect based on a visitor's location can make a search crawler think the original page is no longer the real one. Humans get sent somewhere helpful, but the crawler can lose trust in the page it was trying to index.
How did you find these bugs? By checking the site the way a machine does instead of the way a human does: reading raw page source, following redirect chains, validating structured data and watching the sitemap, rather than just trusting that the rendered page looked correct.
What is the one takeaway for someone building their first site? Your site looking fine in your browser tells you almost nothing about whether a search engine can find and trust it. Check it with tools that see what the crawler sees.
Is this why the NexBDM blog changed? Partly. Every post now carries its own article markup and its own questions, so each page stands on its own for search and for AI answer engines. You can see the wider approach at nexbdm.co.za.