Start with the website and the problem
You do not need to write a detailed technical brief before getting in touch. Send the website address, explain what is happening and tell me what you need to achieve. If an important page has disappeared from search, include that page. If a launch is approaching, include the proposed date. Those details are more useful than a long list of tool scores without the context behind them.
A good first message separates the observation from the explanation. “The service page is returning an error” describes something we can check. “Google does not like the website” is an interpretation that needs more evidence. It is perfectly reasonable not to know the cause. The purpose of a technical investigation is to establish it rather than start by accepting the first theory.
If you are unsure which part of the website needs attention, describe the effect on the business or its visitors. That may be fewer useful enquiries, missing information, a difficult navigation journey or a deployment that changed expected behaviour. I can then help establish which technical questions should be answered first.
Enquiring about a technical SEO audit
For an audit enquiry, tell me roughly how large the website is, which platform it uses and whether a particular section is causing concern. A small professional website and an international catalogue need different collection methods and different levels of sampling. Page counts from a CMS are useful context, but they may not include generated filters, older routes or URLs outside the current navigation.
Explain whether there is an existing development team and how changes are normally released. The useful outcome is a prioritised set of findings that can become implementation work. If development access is limited, that affects how recommendations need to be scoped and which changes can be delivered immediately. It is better to understand those constraints at the beginning.
You can read my technical SEO audit methodology before contacting me. It explains the baseline, evidence and acceptance criteria I want behind a finding. If you already have an audit, send a representative issue and the question that remains unresolved. There may be more value in validating an existing recommendation than commissioning another broad export.
Planning a migration or a redesign
If you are moving a website, include what is changing: the domain, CMS, URL structure, hosting environment, design or content. Several of those changes may be happening together. State whether the old website will remain available during testing and who owns the redirect implementation. Those answers help distinguish a manageable release plan from assumptions that still need resolving.
The current URL inventory matters. A new menu is not a complete record of the pages people already visit or the addresses other websites link to. If you have a crawl, sitemap export or landing-page report, mention that it is available. You do not need to attach a large collection of files to the initial enquiry or send private account access before the scope is understood.
The website migration checklist outlines the stages I would expect to review. A proposed redirect map still needs a live response test after deployment. If the launch has already happened, include the launch date and a small set of old and new URLs that demonstrate the concern. That gives the investigation a concrete starting point.
Content, crawling and JavaScript problems
For a missing-content or indexing enquiry, send the exact URL and explain how you reached the page. A direct visit can behave differently from a route opened through an application menu. Mention whether the information appears immediately, after a delay or only after clicking a control. Include the browser and device if the difference depends on them.
If you have a Search Console example, distinguish the stored result from a live inspection. The dates matter. A report describing a previous crawl is not necessarily a description of the website after its latest release. There is no need to make every report agree before contacting me; a disagreement between two observations can be the clue that narrows the investigation.
The indexing diagnosis guide and JavaScript SEO audit explain the evidence I would use. An accessible response, a complete rendered page and a search engine's eventual indexing decision are separate things. The enquiry should help establish which stage is failing rather than assume they all have the same cause.
Speed and Core Web Vitals enquiries
For a performance problem, include an affected page and describe the part of the experience that feels slow or unstable. Is the main information taking too long to appear? Does the page hesitate after a click? Does a button move while somebody tries to use it? These are different symptoms and they need different evidence.
If you have a test result, include its date, device setting and source. A laboratory run can help investigate a loading sequence or a long task. A field report describes a population of real visits over a reporting window. It is useful to have both, but a high laboratory score should not be treated as proof that every visitor has a good experience.
My Core Web Vitals audit approach explains how I connect the metric with a plausible implementation cause. If a recent release changed images, scripts, fonts or third-party integrations, mention it in the message. The timing may be relevant, but it still needs checking before the change is blamed for the entire problem.
Discussing an employment opportunity
If you are contacting me about a role, send the job description or a short account of the work, the team and the websites involved. I would like to understand how technical SEO fits into the organisation and how recommendations become development tasks. A title alone does not explain whether the role involves investigation, implementation, client communication or a combination of those responsibilities.
Include the location, working arrangements and any important expectations around availability. I am based in Bournemouth, Dorset, with professional experience across UK and multilingual websites. My background includes SEO, website design and maintenance, hosting, domain administration and digital marketing. The About page explains how those areas connect with the technical work.
The homepage retains my employment history. The technical guides provide another way to assess how I approach an investigation and explain a change. I am happy to discuss a relevant example, but private client material and account data need the appropriate permission before they can be shared.
Send useful evidence, not account passwords
A short description, a few URLs and the date the issue was first noticed are usually enough for the initial conversation. If a screenshot is important, explain what it demonstrates and which page it came from. A screenshot of a warning without the affected address or test conditions often leaves more questions than it answers.
Please do not send passwords, API secrets, recovery codes or sensitive customer information through the form. If account access becomes necessary, the method and permissions can be agreed once the work is defined. The same applies to large crawl files and server logs: establish what is useful and remove unrelated information before transferring it.
The SEO evidence workbench can help structure an observation before it becomes a ticket. Its downloadable packet asks what would disprove the diagnosis, which control page should remain unaffected and what would trigger a rollback. You do not need to use the tool to contact me, but those are useful questions when several teams are discussing the same issue.
What the first conversation needs to establish
The first step is to understand the desired outcome, the affected scope and the practical constraints. From there, the work can be framed as a focused investigation, a broader audit, a release review or ongoing technical support. I would rather agree a useful question at the outset than produce a large report that does not resolve the reason you got in touch.
A sensible brief also identifies who will implement the change and how it will be checked. If the website is managed by another supplier, that does not prevent an investigation, but the responsibilities need to be clear. A recommendation should give that team something specific to review rather than leave it to interpret a vague request to improve SEO.
You can use the form, email me@richieaubin.com or call 07887 423199. If the form reports a delivery problem, use those direct details. Technical implementation can be checked against agreed requirements; rankings, indexing choices and the timing of search-engine processing cannot be promised as part of an initial enquiry.
Frequently asked questions
What should I include in my first message?
Include the website address, the affected page or section, the behaviour you are seeing and the outcome you need. If the issue followed a release, include the release date. A few specific examples are a better starting point than a large collection of unexplained screenshots.
Do I need to send account access straight away?
No. Do not send passwords or access secrets through the form. An initial conversation can establish the scope and the evidence that would help. Any access requirements and permissions can then be agreed through a suitable method.
Can I contact you about an employment opportunity?
Yes. Send the role description, the team structure, working arrangements and the kind of websites involved. My professional background and employment history are available on this website, alongside practical guides that show how I approach technical investigations.
What if the contact form does not send?
The page will show an error and keep the details you entered. You can email me@richieaubin.com or call 07887 423199 instead. If the connection limit has been reached, wait before trying again rather than repeatedly submitting the same message.