Before we started offering technical SEO as a service, we did the thing most agencies skip: we pointed the process at ourselves.
We ran a full technical audit on prixelo.com. Not a staging environment, not a demo site — the real site, the one prospective clients look at before they email us. We expected a handful of small issues. We found seven things that were actively working against us.
This post is that audit, unedited. No composite client, no invented case study. Just what we found on our own site and what each bug teaches about how search engines actually see a page versus how a browser renders one for you.
The sitemap was missing most of the site
We pulled up sitemap.xml expecting a formality. Instead we found a file listing a fraction of our real pages. Whole sections of the site — pages we'd shipped, linked internally, and expected to rank — simply weren't in it.
A sitemap isn't a nice-to-have. It's the map you hand Google so it doesn't have to guess at your site structure by crawling links alone. A page that's live, internally linked, and absent from the sitemap can still get indexed eventually, but it's slower, less reliable, and it signals to crawlers that your site's metadata isn't trustworthy. If the sitemap is wrong once, a crawler has less reason to treat it as authoritative anywhere else.
Our Organization JSON-LD had been broken sitewide
We check structured data with a validator as a matter of habit. Ours failed. Every page.
The cause was a template-escaping bug — a character in our Organization schema was being encoded incorrectly at render time, which meant the JSON-LD block was syntactically invalid on every single page it appeared on. Google doesn't partially parse broken JSON. It either parses cleanly or it discards the entire block. So for however long this had been live, we had zero structured data reaching Google, sitewide, while believing we had full markup. This is the kind of bug that produces no error in a browser — the page looks fine — and no warning unless you specifically go looking for it in a schema validator or Search Console's rich results report.
Soft-404s returning HTTP 200
Some broken or removed URLs on the site weren't returning a 404 status. They were serving fallback content — a generic page — while the server told the browser and every crawler "200 OK, this page exists."
That's a soft-404, and it's worse than a real one. A true 404 tells search engines clearly: this URL is gone, drop it from the index. A soft-404 tells them: this URL is fine, please keep crawling and indexing it, even though there's nothing here. Left alone, this wastes crawl budget on pages that don't exist and can dilute how your real pages get evaluated, because the crawler is spending time and trust on dead ends that claim to be live.
Canonical tags pointing at the wrong domain
Several pages had canonical tags referencing the non-www version of our own domain, which itself redirects elsewhere — a leftover from an earlier setup. A canonical tag is a direct instruction to search engines: "index this URL as the authoritative version, not the one you're currently looking at." When it points somewhere wrong, you're explicitly telling Google to credit a different URL for your own content. Best case, it's ignored. Worst case, you're actively routing your own ranking signals away from the page that needs them.
Meta descriptions truncated mid-word
Smaller, but it's the kind of thing that erodes trust in aggregate: several meta descriptions were being cut off mid-word in the raw HTML, not just truncated for display in search results. That's a template or character-limit bug, not a display artifact, and it shows up as unfinished sentences sitting in your <meta> tags — visible to anyone who views source, and a small but real signal of carelessness on a page that's trying to look credible.
A stale robots.txt from a directory that predated the current site
This was the strangest find. The robots.txt being served wasn't the one in our current codebase. It was coming from a leftover legacy directory on the server — a remnant of a previous version of the site that should have been retired entirely. The live application had no idea this file existed or that it was the one crawlers were actually reading.
robots.txt is one of the first files a crawler requests. If the version being served is stale, it can be blocking paths that should be crawlable, allowing ones that shouldn't be, or just pointing to a sitemap that no longer exists. And because it lives outside your normal deploy path, it's invisible to anyone checking the current codebase — you have to check what's actually being served at the URL, not what you think you shipped.
Pages that told crawlers "not found" because of client-side-only slug detection
The last one is a JavaScript rendering issue, and it's a common trap for anything built with client-side routing. Certain pages determined which content to show based on a slug that was only resolved in the browser, after the JavaScript ran. Crawlers that don't fully execute client-side JavaScript — or that time out before it resolves — hit the initial server response, find no matching slug, and get served a "not found" state. The page works perfectly for a human. It's invisible or broken for a crawler that never gets far enough to see the real content.
What this actually teaches
None of these bugs are exotic. They're the standard failure modes of any site that's grown past its first version: legacy infrastructure nobody decommissioned, a template change that quietly broke encoding, a routing pattern optimized for users but never checked against how crawlers behave. Every one of them was invisible in a normal browser and invisible unless someone went looking specifically for how a crawler sees the page, not how a person does.
That's the actual job. Technical SEO isn't keyword suggestions or content calendars — it's finding the gap between what your site looks like to you and what it looks like to the systems deciding whether to index and rank it. We fixed all seven issues on our own site as part of building out our SEO service, because we weren't going to sell an audit we hadn't first run on ourselves.
If you want to know whether your own site has versions of these same problems, that's exactly what our SEO team checks first — before any conversation about content or rankings.
