Read the scope before the outcome
A useful project account should explain what the person actually did. A redesign, a server move, an SEO programme and an ongoing marketing role can overlap, but they are not the same assignment. Without that distinction, a portfolio screenshot tells you very little about the technical decisions behind the website.
The examples below explain the work involved and the technical responsibilities behind it. A useful account needs more than a finished screenshot: it should help you understand the role, the platform constraints and the decisions that had to be made. Where performance figures are not supported by a defined baseline and comparison period, I focus on the scope and delivery instead.
For a technical discussion, I would rather begin with a concrete implementation: a route that had to keep working during a move, a CMS template that controlled several pages or a language relationship that needed to remain consistent. The technical audit methodology explains the evidence I would use to investigate and verify that kind of work.
Domus Venari: websites, SEO and online marketing
My role with Mertex Investments, the business behind Domus Venari, ran from 2012 to 2024. The work included creating and redesigning company websites, day-to-day website maintenance, marketing campaigns, on-site and off-site SEO, and PPC during part of that period. The websites operated in up to ten languages.
That is a broad operational role rather than a single isolated SEO intervention. It involves keeping the website useful while content, inventory and marketing requirements change. A property business needs clear routes into current listings and service information, but it also needs a maintainable approach to older URLs and language versions. Those requirements have to fit the way the actual platform works.
The relevant technical methods are covered in the international SEO guides and the site architecture cluster. Those guides explain how I would inspect relationships and diagnose failures. They should not be read as a claim that every example shown in a guide occurred on this particular project.
ADH Asesoria: redesign, SEO and server migration
My work for ADH Asesoria covered website design, SEO and a server migration. That included redesigning the English and Spanish websites and carrying out a programme of SEO work. For a professional services website, the practical challenge is to keep information clear and contact routes dependable while the underlying implementation changes.
A migration needs more than a successful request to the homepage. Existing service URLs, language versions, images and form destinations all need an explicit check. If the new server differs in its rewrite behaviour or directory handling, an old URL may fail even though the new navigation appears correct. These are the sorts of differences a pre-launch inventory should expose.
The website migration checklist sets out the stages for planning and verification. It distinguishes a redirect decision from the test of the implemented redirect. A successful move depends on understanding both the existing website and the new environment. The guide provides a reusable way to organise that work, with enough detail for the person implementing the change and the person reviewing the result.
Resale Centre: website operations and lead generation
My work with Resale Centre included website maintenance, SEO, marketing, email campaigns and support for a network of estate agents. I designed and built more than eight websites over five years, alongside the wider website and marketing responsibilities in my 2005 to 2012 role. The project work also included PPC marketing, with the practical aim of generating useful enquiries rather than treating the website as an isolated design exercise.
Working across several websites makes consistency an operational issue. A content or template decision needs to remain understandable across the estate. A broken contact route is a practical business problem whether or not it appears in an SEO report. Similarly, a growing collection of pages needs a clear purpose and a useful path from the rest of the website.
The internal linking audit guide explains how to examine those paths. It starts from the destination's purpose and current links, rather than adding repeated anchors wherever a phrase appears. The technical monitoring guide covers the checks that help keep important routes working after the initial project.
Hampshire Architecture and other website builds
My work for Hampshire Architecture covered the website and a server migration. For SP Costa del Sol, the work included a custom CMS template, PPC and marketing. For Platinum Holiday Rentals, it included a custom CMS template, SEO and marketing. The work spans different businesses, but it shares a practical requirement: the design has to result in a usable, maintainable website.
A custom template determines more than appearance. It controls headings, navigation, content placement, asset requests and, often, the metadata that search engines receive. A well-designed editor experience can still produce poor output if those decisions are inconsistent. Template review therefore needs to examine the response HTML as well as the rendered page.
The SEO release QA checklist and image performance guide describe useful checks around that work. The aim is to protect the information and journeys people need while avoiding unnecessary loading and rendering costs. A visual refresh should not quietly remove the content or links that made an existing page useful.
Appius: technical SEO alongside development teams
My current Appius role focuses on technical SEO audits for agency clients using platforms including Sitecore, Sitefinity, Umbraco and Optimizely. The work included reporting issues, identifying changes and giving developers clear fixes. This is where the quality of the handoff becomes particularly important.
An issue may appear on a single inspected page while the responsible rule affects an entire template. Conversely, an apparent template pattern may be caused by one editor's content choice. Establishing that scope prevents a team from applying a broad fix to a local problem or treating a platform issue as dozens of separate content tasks.
The prioritisation framework and regression testing guide explain how to move from an observation to a controlled change. I have not disclosed private client names, account data or project outcomes here. Those details need the appropriate evidence and permission before they belong in a public case study.
What a detailed technical case study should contain
A properly evidenced case study starts with the original problem and its scope. It should show the affected URLs or template, the observation dates, the measurement conditions and the reason the issue mattered. If a result is attributed to one change, the account should also explain what else changed during the same period.
The diagnosis needs to show a chain of reasoning. A report warning is an observation, not automatically a root cause. State which competing explanations were checked and why the chosen repair followed from the evidence. Include the implementation requirement and the acceptance test so that a technical reader can assess whether the proposed change addresses the original failure.
The outcome should distinguish implementation success from business performance. A redirect can be verified immediately after deployment. Organic traffic may require a longer comparison window and careful interpretation of seasonality, demand and other changes. A case study is more persuasive when it acknowledges those limits than when it presents every subsequent improvement as proof of one technical fix.
How to discuss a relevant example
If you are assessing me for a role or a project, start with the type of problem you need help solving. A migration discussion needs different detail from an audit handoff or a multilingual template review. The about page gives the wider professional background, while the homepage retains the full employment history and published testimonials.
You can also inspect the SEO evidence workbench and the technical knowledge hub. They provide a practical view of how I structure a question, check a dataset and explain the next step. The tools make their boundaries visible: an exported redirect map is not the same thing as a live response test.
For an initial conversation, send the URL, a short description of the assignment and the outcome you need. If the work involves private data or previous client records, we can establish what can be shared before discussing the detail. Contact me at me@richieaubin.com or on 07887 423199.
Frequently asked questions
Are the examples above full performance case studies?
They are summaries of my project experience. They explain the role, the type of work and the implementation issues involved. A full performance case study would also need the original measurements, comparison period, implementation evidence and permission to disclose the relevant details.
Why are there no new traffic growth percentages?
A percentage without a clear baseline and measurement method is difficult to assess. I have not added unsupported numbers to make the projects appear more impressive. Technical delivery can be described precisely while keeping separate any result that would need additional records to substantiate it.
Can you discuss a migration approach before a project starts?
Yes. A useful discussion begins with the existing URL estate, the proposed changes, the launch arrangements and the teams involved. The migration guides explain the questions and checks I would use. Project-specific recommendations still require the actual inventory and implementation details.
Where can I see how you approach technical investigations?
Start with the technical SEO hub, the audit methodology and the release QA guide. They show how I separate observations from causes, write a development requirement and verify a change. The evidence workbench adds inspectable examples of checks that can be performed on exported data.