Case study / Our own website

We Audited Our Own Site and Found Our Own Mistakes

This is the only case study here you can check line by line, because the client is us. Every claim on this page can be confirmed by viewing the source of our own pages, including the things that are still wrong.

At a glance

Client: PIXELS TRAIL. We were our own client, which is why nothing here needs permission.
Scope: 120 commercial pages, plus the theme, footer and feed behaviour
Period: Completed October 2026
Why it is here: It is the one engagement on this site you can verify yourself, in your own browser, in about ten minutes
Honest summary: We found most of the problems we charge clients to fix, on our own website

120

Commercial pages now serving one identical structured data graph, instead of several competing versions.

129

Duplicate structured data records removed, each of which was fighting with the one we had written.

4

Separate places the same outdated claim about our own experience was hiding, only one of which was page text.

0

Published pages now missing a title tag or a meta description.

Unlike the other two case studies on this site, you do not have to take any of this on trust. The section below called how to check this yourself gives you the exact steps, and the section on what is still wrong lists the things we have not fixed.

Why we audited our own site at all

We sell search, structured data and brand work. Our own website had been built up over years, page by page, by the same process as most of our clients’ sites: whoever was free, whatever was urgent, nobody auditing the whole thing because it was nobody’s job.

The trigger was a simple question. We had built a tool that scores how readable a page is to AI assistants, and we ran it on our own pages. The results were worse than we expected, and worse than several client sites we had worked on.

That led to a full rebuild of the service pages onto one structure, and then to a series of audits that each found something we had not been looking for. Several of the worst problems were ones we had introduced ourselves while doing the rebuild, which is the part most case studies would leave out.

Writing this up matters commercially, because a prospect asking whether we are any good at technical search work can check our own site instead of believing a claim. That cuts both ways, which is why the list of what is still wrong is on this page too.

What the audit found

Three problems stand out, and all three are common on sites we audit for clients. We had them anyway, which is the point of publishing this.

Our pages were serving two structured data graphs at once

Forty five pages carried two Service entries sharing one identifier. About 87 percent of those also served two sets of frequently asked questions, ours with fifteen and a stale one with five, and six pages described themselves as the wrong type of thing entirely. Search engines were being given two different answers on the same page.

One outdated claim was living in four separate places

A stale statement about how long we had been working appeared in page text, in the theme options that print on every page, inside a footer template, and as plain numbers inside counter widgets. Only the first of those is findable by searching the page text, which is why three of the four survived the first fix.

We were quoting statistics we could not source

Several figures in our copy were the kind that circulate without an origin. When we went looking for the primary source, we could not find one for any of them. They read well and they were not defensible.

What made this harder than it sounds

These are the practical constraints that shape any change to a live site, and they are the reason this work is slower than it looks from outside.

▶A live site with traffic and no staging copyEvery change had to be made in place, on pages people were landing on, which means every destructive change needed a backup written first and a way to undo it in one step.
▶The page builder stores each page as one blobElementor keeps a page's entire content in a single serialised field. There is no editing one paragraph at the database level. A bad write does not corrupt a section, it replaces the page.
▶Two systems were both writing to the page headOur structured data is written into the page, and the search plugin generates its own independently. The switch that suppresses the plugin's version is set per page and easy to miss, which is exactly how the duplicates happened.
▶Some numbers were invisible to any text searchCounter widgets store their figure as a setting rather than as text. Searching the site for the outdated claim returned nothing for those, and they kept displaying it.
▶We were the client, so nobody was policing scopeThere was no budget conversation to stop us and no approval gate. That sounds like freedom and mostly means the work expands until someone decides it is finished.

What we changed

Ordered roughly by how much difference each one makes to someone evaluating us.

One layout across every service page

Forty five service pages rebuilt onto a single structure, generated from a configuration file rather than laid out by hand, so the pattern is identical everywhere and a change to the pattern reaches all of them.

One structured data graph across 120 pages

Service, location and industry pages now serve the same six entity types with consistent identifiers, and the competing records were removed rather than patched.

Feeds and embeds kept out of the index

A small must use plugin sends a noindex header on feed and embed responses and stops the page head advertising comment feeds. Those responses are XML and JSON, so a meta tag cannot reach them and a header is the only instruction that works.

A scoring tool for AI readability

A thirty two check scanner across five weighted categories, which is what started this whole exercise. It is our own tool and we are explicit about that below.

A backup for every destructive change

Before each pass, the previous state was written to its own record. One of those backups was used, when a fix broke grammar across seventy eight pages and everything had to go back.

A validator that runs before anything publishes

Checks structure, banned characters, metadata lengths, internal links and sentence length. It refuses to publish on a dead internal link, which has already stopped one broken page going live.

What we decided not to do

Each of these was the more impressive looking option, and we are recording why we passed on it.

✕We did not move to a new theme or builderStarting clean is more satisfying and would have been easier to write about. It also throws away years of working pages to solve problems that were fixable in place, and it is the advice we would refuse to give a client in the same position.
✕We did not keep the statistics we could not sourceThey were persuasive numbers and removing them made some sections weaker. A figure we cannot trace to a source is a liability on a page that sells research driven work, and we would rather have a thinner claim than a borrowed one.
✕We did not block the feeds in the robots fileBlocking them looks like the direct fix. It also stops search engines fetching the pages, which means they never see the noindex instruction, so the URLs sit in limbo instead of dropping out. The slower route is the one that works.
✕We did not extend the graph to the whole site in one goThe home page, the about page and the portfolio galleries still use the search plugin's generic output rather than our own graph. Doing all of them in the same week as two larger changes would have meant rushing the part that is hardest to reverse, so twenty eight pages are still waiting.
✕We did not delete the backup recordsThey take up database space and a tidier site would have cleared them. Keeping them means any of these changes can still be reversed, which matters more than a clean table.

What is now true

Each of these is checkable from outside, and the next section tells you how.

✓Every commercial page serves exactly one structured data graphOne block, six entity types, consistent identifiers, no duplicate entries and no stale questions.
✓The outdated experience claim is gone from all four placesPage text, theme options, footer template and the counter widgets.
✓Feed and embed URLs tell search engines not to index themSent as an HTTP header, which is the only method that reaches a response that is not HTML.
✓No unsourceable statistic remains in our copyWhere a figure stayed, it has a named primary source and a date. Where we could not find one, the figure went.
✓No published page is missing a title tag or a meta descriptionChecked across the whole site rather than sampled.
✓Every page we rebuilt has exactly one top level headingIncluding these case study pages, which initially had two because the theme adds its own banner and we had not suppressed it. We caught that on this page.

What is still wrong, and what we have not measured

This is the part that makes the rest of the page worth reading. If we only listed wins you would have no way to judge whether the list was complete.

⚠We have not measured whether any of this improved our rankings or our enquiries. The work finished in October 2026 and there has not been enough time for an honest before and after. Anyone presenting you a result from a change made three weeks ago is showing you noise.
⚠The score we quote from our own AI readability tool is from a scanner we wrote. We chose the thirty two checks, we set the weightings, and then we passed our own test. Treat it as a structured checklist we find useful, not as an independent grade, and be suspicious of any agency quoting you a proprietary score as though it were a standard.
⚠The feed change is not finished in practice. Those URLs still appear in Google Search Console as crawled and not indexed, and they will move to being excluded by a noindex tag over a period of weeks as the pages get refetched. That is the expected path, not a completed outcome.
⚠At the time of writing, twenty eight of our 156 published pages still fall back to the search plugin's generic output rather than carrying our own graph. They include the home page, the about page and the portfolio galleries. That is a real gap rather than a finished job, and it is the next thing on the list.
⚠At the time of writing, thirty one page titles are longer than sixty two characters and forty two meta descriptions are longer than a hundred and sixty, which means search engines will truncate them in results. Not broken, and not finished.
⚠The rebuilt service pages are heavy, roughly 294 KB of HTML each. We have not optimised that, and page weight is something we would raise with a client, so it belongs on this list.
⚠Four of our twenty three published posts are thin, between about 250 and 550 words, and two slugs still carry the year 2025 in them, which will date badly. Both are on the list and neither is done.

How to check this yourself

This is the whole reason this case study exists. Five checks, no tools beyond a browser, and they will also find anything we have overclaimed.

01 View the source of any service page and search for ld+json

Open any page under our services, view the page source, and search for application/ld+json. You should find exactly one block. If you find two, we have regressed and we would like to know.

02 Check the headers on a feed URL

Request any feed URL on this site and look at the response headers for X-Robots-Tag. It should read noindex, follow. Normal pages should not carry that header at all, which you can confirm on this page.

03 Search our site for the outdated experience claim

Use a site restricted search for the kind of phrase an agency usually leaves lying around about years of experience. You should not find a stale version anywhere, including in the footer.

04 Run any page through a structured data validator

Google’s Rich Results Test and the Schema.org validator both accept a URL. Check that the entities come back as one coherent set with no duplicate identifiers and no conflicting entries.

05 Count the top level headings

Search the page source for the opening h1 tag. On any service page or case study there should be exactly one. This is the check that caught our own mistake on these very pages.

What we would do differently

We should have audited the structured data before writing forty five pages of it rather than after. The duplicate graph problem existed on every page we built, from the first one, and we found it only because a direct question was asked about whether the schema was working. An hour of checking at the start would have saved the entire remediation pass.

The outdated years claim taught us something we now apply to every client site. A fact in a content management system almost never lives in one place. Our first attempt at fixing it rewrote sentence structure with a phrase map and produced broken grammar across seventy eight pages, which we had to restore from backup before doing it properly. The lesson was not about years, it was about never letting a bulk text replacement change sentence structure.

The validator should have existed before the first page, not after the twelfth. Everything it checks is something we got wrong manually at least once, which is exactly the list a validator should have been built from on day one.

We should have recorded a baseline before touching anything. Not a sophisticated one, just the rankings, the enquiry count and a few AI assistant answers about us, saved on a given date. We did not, which is why the section above has no measured result and why we now ask clients for this before quoting.

The services this work came out of

Everything described here is work we do for clients, and these pages set out the method and the pricing.

Other case studies

The same work, for a client

Structured data, content and AI discoverability across a corporate investigation group of ten websites.

A brand arguing against its own pitch

The 2014 identity rebrand that started our longest running client relationship.

An eight year white label partnership

A Dallas marketer sold, we delivered. More than 150 small business websites between 2013 and 2021.

Questions people ask about this one

Is a case study about your own website not a bit convenient?

It is the opposite of convenient, because it is the only one you can audit. A client case study is something you have to believe. This one you can check, including checking whether the list of remaining problems is honest. If we had wanted an easy page we would have written about a client and shown you a chart.

Why publish the things that are still broken?

Because a list of only wins tells you nothing about whether the list is complete. Any agency can show you the good half. Publishing the unfinished half is the only way to make the finished half mean anything, and it also commits us to fixing it.

You said you introduced some of these problems yourselves. Which ones?

The duplicate structured data was ours. Our pages carried a correct graph and the search plugin was adding a second one, which we did not notice until the schema was checked properly. Two pages had the same fault as recently as the week this page was written, and were fixed while writing it.

What is a structured data graph and why does serving two matter?

It is machine readable information in the page describing what the page is and who published it. Serving two means a search engine gets two answers to the same question, sometimes contradictory, and it then decides which to believe. That is a decision you want to make rather than delegate.

Why can a meta robots tag not stop feeds being indexed?

Because a feed is XML rather than HTML, so there is no head section for a meta tag to sit in. The only instruction a search engine can read for a response that is not HTML is an HTTP header. This is why plugin settings for noindex do not solve this particular problem, whatever their interface implies.

Would you do this to our site?

Yes, and the audit comes first as its own deliverable so you can see what we found before committing to a rebuild. Quite often the audit shows that a rebuild is not what is needed, which is the outcome we would rather reach before taking money for one.

How long did this take?

The service page rebuild and the schema work ran across several weeks of concentrated effort, not continuously. For a client we scope the audit separately from the remediation, because the audit is what tells you how big the remediation is, and guessing before that means padding the number.

Do we need all of this, or just some of it?

Almost certainly just some of it. The structured data and the metadata checks are worth doing on nearly any site. The full layout rebuild only pays for itself when you have enough similar pages that one pattern can serve all of them, which for us was forty five. With five pages it would have been the wrong call.

What did the AI readability tool actually change?

It changed how the pages are written rather than how they are coded. Clearer definitions near the top, figures with sources attached, shorter sentences and answers that can be lifted out of the page without the surrounding context. It is worth saying that most of that is just good writing, and it would have helped a human reader too.

Who did this work?

Swaranjit Singh, who runs PIXELS TRAIL, which is also why the mistakes in it are attributable to one person rather than spread across a team.

Want to know what an honest audit of your site would find?

That is the deliverable, before any rebuild is discussed. You get the list of what is wrong, ranked by what it costs to leave alone, including the parts that are not worth fixing. If the answer is that your site is mostly fine, that is what the report will say.