A background that connects SEO with the website itself

My experience has not been limited to writing recommendations for somebody else to interpret. It includes building and maintaining websites, working with hosting platforms, administering domains and supporting the marketing activity that brings people to those sites. That wider background is useful in technical SEO because the cause of a search problem does not necessarily sit in the SEO settings.

A redirect might be controlled by the web server. A canonical might be supplied by a CMS template. An image may be resized correctly in the editor while the page still downloads the original file. An access rule may work for normal visitors and challenge a crawler. Knowing where to look helps turn a vague complaint about visibility into a specific investigation.

I do not expect every business owner to understand the implementation. I do expect the explanation to be clear enough that they can understand the problem, the consequence and the next decision. Developers need a more precise version of the same information, including the conditions that reproduce the issue and the behaviour the finished change should deliver.

Working with Appius in Bournemouth

My current role at Appius focuses on technical SEO for a web development agency. The work includes auditing websites, identifying technical issues, reporting findings and giving the development team clear fixes. The CMS platforms involved include Sitecore, Sitefinity, Umbraco and Optimizely. These environments make it particularly important to distinguish a content change from a template or platform change.

A recommendation that sounds simple in a spreadsheet can affect several templates, languages or integrations. The useful question is how to make the intended behaviour consistent without breaking the parts that already work. That is why my technical audit methodology includes scope, evidence and implementation checks rather than stopping at an issue count.

The work also requires a sensible distinction between a technically valid implementation and a business priority. A website can contain many imperfect details, but not all of them have the same effect on people finding or using it. I want the development time to go into problems we can explain and changes we can test.

Experience with multilingual property websites

Before returning to the UK, I spent 19 years living and working in Spain. A substantial part of that experience involved property businesses, including Domus Venari and Resale Centre. The work covered website design and maintenance, SEO, marketing, lead generation and, during part of that period, PPC. Some websites operated in up to ten languages.

Multilingual work makes the relationship between content, URLs and templates very clear. A change needs to make sense in the actual language version, not simply appear correct in the default site. Navigation, regional context and translated page relationships all deserve checking. The international SEO guides explain the technical side of those relationships without treating hreflang as a substitute for useful local content.

Property websites also bring together large inventories, changing availability and enquiries that matter to a sales team. That combination encourages a practical view of SEO. The aim is not to create the largest possible number of indexable URLs. It is to help people reach useful, current information and make the next step straightforward.

Websites, hosting and migrations

My project history includes work for legal services, property businesses and other professional organisations. The project experience page covers website builds, ongoing SEO work and server migrations. It explains the scope of each assignment and connects the work with the technical methods used to plan and verify a change.

Moving a site is a good example of why technical detail and business context belong together. The new website can look correct while old landing pages stop working, a server rule sends visitors to an irrelevant destination or a file reference still points at the previous environment. A launch check needs to cover those routes as well as the homepage.

I have used cPanel, Plesk and other hosting interfaces, alongside domain and registrar administration. That experience helps with the questions around ownership, access and configuration that can slow down an investigation. The migration guides describe the decisions and tests that make that work easier to organise.

How I want an audit to be used

An audit should be a working document. If the reader has to guess which pages are affected or what the replacement behaviour should be, the finding is not ready for implementation. My preference is to show a representative example, establish the wider pattern and write down what should happen after the change.

That also means being direct about uncertainty. A crawl can establish what a server returned during a request. It cannot, on its own, establish why every search result changed. A field performance report describes a population and reporting window. It does not necessarily isolate the line of code that caused a delay. The evidence should support the claim being made.

The issue prioritisation guide explains how I separate exposure, likely effect, confidence and delivery effort. A business does not need an inflated list of emergencies. It needs a sensible order of work and a clear account of what each completed change has resolved.

Communication with developers and stakeholders

Different people need different levels of detail, but they should be looking at the same underlying finding. A stakeholder needs to understand the effect on the website and the reason for the priority. A developer needs the affected component, reproducible steps, relevant examples and an acceptance test. Neither benefits from an unexplained export full of warning labels.

I favour short, concrete explanations. If an important page returns an error, say which page, which response and under what condition. If a navigation feature does not expose useful links, show the HTML and the missing route. The strongest explanation is often the one that makes the next action obvious.

Acceptance criteria also make review less subjective. A requirement such as “improve internal linking” leaves room for a large amount of interpretation. A requirement that identifies relevant source pages, the intended destination and the expected crawlable link gives the team something it can deliver and verify. The release QA guide develops that approach.

What you can inspect on this website

The technical SEO knowledge hub is organised around the problems I want a reader to be able to investigate. It covers crawling, rendering, architecture, auditing, performance, structured data, migrations, international implementations and automation. The pages link to related investigations so that a symptom can lead to the next useful check.

The SEO evidence workbench provides small, inspectable checks for exported data. It is designed around a defined input and a limited claim about the output. For example, a redirect map can be checked for conflicting rules without pretending that the file proves how a live server responds. That boundary is part of the tool's usefulness.

Examples using invented URLs are labelled as illustrative. I do not want a demonstration to be mistaken for a verified client result. Where a professional claim needs a baseline, a measurement window or permission to disclose the work, those requirements should be respected rather than replaced with a convenient percentage.

Discussing a role or a technical project

I am interested in opportunities where technical SEO is connected to the work of improving websites. That can involve an in-house role, an agency team, consultancy or an individual technical project. I am open to discussing work across Dorset and Hampshire, including Bournemouth and the surrounding area. The best starting point is a clear description of the work and the outcome you need.

For an existing problem, send the affected URL, the behaviour you are seeing and any relevant timing. If a release or migration happened shortly before the problem, include that context. There is no need to send passwords or private account access in an initial message. A useful first conversation can establish the scope before any access is arranged.

For a role, I would like to understand the team, the websites involved and how technical recommendations become development work. You can contact me at me@richieaubin.com or call 07887 423199. The homepage retains the wider employment history and published testimonials.

Frequently asked questions

Where are you based?

I am based in Bournemouth, Dorset, and I am open to discussing opportunities across Dorset, Hampshire and the surrounding area. If you have a role or a specific project in mind, send the location and working arrangements with the initial enquiry so that we can discuss the practical details.

Which CMS platforms have you worked with?

My experience includes WordPress, Joomla, Sitecore, Umbraco, Optimizely and Sitefinity, alongside static websites and custom templates. The important part of an investigation is identifying where the behaviour is controlled. A CMS label alone does not explain how a particular website has been implemented.

Can you work with an existing development team?

Yes. My current technical SEO work includes identifying issues and giving a development team clear fixes. I want the brief to include enough evidence and acceptance criteria that the implementation can be reviewed without guesswork. Access, release ownership and the review process can be agreed around the project.

Can you guarantee a ranking increase?

No. A responsible technical SEO brief can specify an implementation, explain the reason for it and define how to verify the change. It cannot guarantee how a search engine will rank a page. The practical objective is to remove demonstrated obstacles and improve the website in ways the team can inspect.