Car Manual All Makes

This project wasn't just an exercise in SEO theory. Our founder, Robert, trained as a motor mechanic and worked in a garage before spending fifteen years in SEO. That hands-on experience was the foundation of the whole strategy. We didn't need to guess what drivers search for; we knew from experience how they describe faults and what they need to know.

A mechanic diagnoses problems by starting broad and getting specific: Make > Model > System > Fault. We built the website's structure to mirror that exact logical process. This isn't just about organising content. It's about matching the user's thought process from the moment they type their problem into Google to the moment they find the answer. This grounding in reality is what separates a useful resource from a keyword-stuffed content farm.

The original case study mentions we cut weak pages. But what makes a page weak? It's not just about low traffic. We look for signals in Search Console that tell us a page isn't doing its job properly. A page might get thousands of impressions but very few clicks, which tells us its title and description don't match what the searcher wants. Or it might get clicks, but visitors leave immediately, meaning the content itself misses the mark.

When we find a weak page, we don't just delete it. First, we decide if the topic is still valuable. If it is, we'll completely rewrite the page to better answer the user's question. If two pages are competing for the same search query, we merge them into one stronger article. We only delete a page if the query it targets is irrelevant or has no real search demand. It's like pruning a tree; you have to remove the unproductive branches to let the healthy ones grow stronger.

A large site can feel like a maze. Our internal linking strategy was designed to create clear pathways for both users and search engines. It's not about randomly linking keywords; it's about building a logical web of information that shows how different topics relate to each other.

A page about a specific EGR valve fault on a Ford Mondeo, for example, will link 'up' to the main Ford Mondeo page. It will also link 'sideways' to a general article explaining what an EGR valve does, and to other common faults for that model. This helps a user explore the topic more deeply and signals to Google that we have a whole cluster of expertise around that area, not just one isolated page. This is how you build authority at scale.

Structured data, or schema markup, is code that explicitly tells search engines what your content is about. For a site with thousands of technical pages, it's essential for providing clarity. We didn't just add generic markup; we matched it to the content on the page.

For articles explaining a repair procedure, we used `HowTo` schema to outline the steps. For pages built around a specific question, we used `FAQPage` schema. This helps Google understand the exact purpose of the page and can lead to 'rich results', like showing the steps or answer directly on the search page. It's a way of spoon-feeding the information to search engines, ensuring they can tell the difference between a page defining a part and one explaining how to fit it.

It's tempting to look at a project like this and think you can use AI to generate thousands of articles automatically. This is the fastest way to create the exact kind of thin, repetitive content that Google penalises. We see AI as a powerful tool for assistance, not a replacement for human expertise and effort. Our founder's dyslexia and ADHD mean he has always relied on tools to organise thoughts and structure work, and our approach to AI is an extension of that philosophy.

We use modern tools to analyse search data at scale, identify patterns in user questions, and help create detailed outlines for our writers. But the actual writing, the fact-checking, and the crucial step of ensuring the advice is safe and accurate—that is always done by a human. It's the only way to stick to our rule: scale the structure, but never, ever scale thin, automated content.