Most SEO work is content work. On a large site, a dynamic one, or one where the platform itself is unstable, the binding constraint is somewhere else — and it cannot be resolved from a content editor. We work on that layer.
A site with a million URLs has a handful of page types, and the discoverability of every one of them is decided by decisions made long before anyone considers SEO: how routes are generated, how content is versioned, how pagination works, what the sitemap contains, and whether freshness is expressed anywhere in the system. Those decisions have owners. Their search consequences usually do not.
Each links to the full capability page — the problem it addresses, how we work, and the evidence behind it.
When content is good and rankings still fall, the cause is usually in how the site is served rather than what it says. We diagnose that layer directly — crawl behaviour, rendering, server responses, indexation — and fix it at the source.
Most audits are a document. What a team actually needs is a set of findings grouped by the fix that resolves them, ordered by evidence, and written in a form that can go into a tracker without being rewritten.
Most technical SEO recommendations are correct and never ship. The gap is rarely diagnosis — it is that the fix lives in a repository, a template or a server configuration, and the person who found it does not write to any of them. We close that gap.
Discoverability is an architectural property. This is the work of designing it into a platform — how content is structured, discovered, refreshed and prioritised — rather than treating it as an audit finding to be patched afterwards.
AI answers are becoming a distinct layer of discovery. We can improve the conditions that make a page citable and measure whether citing happens. We cannot make an AI system cite you, and any agency claiming otherwise is selling something it does not control.
This is a measurement service and not a way to earn citations. What it establishes is whether a set of queries produces answers that reference your site — and what the instrument can and cannot tell you.
Pages that are crawled but not indexed are the most commonly misdiagnosed problem in technical SEO. It is not one problem. It is at least four, they present identically, and they have opposite remedies.
Core Web Vitals are unusual among search signals in that they are measurable in the field, attributable to specific engineering causes, and still routinely unfixed. The reason is rarely that nobody knows what to do. It is that the fix belongs to a template, a render path or a server, and the person who diagnosed it does not own any of them.
A search engine that repeatedly meets errors during a visit does not complain. It reduces how often it comes back. That decision is slow, invisible and frequently the real cause of an impression decline that is being investigated as a content problem.
Most sites have a sitemap. Far fewer have one that is complete, accurate and generated from the same source as the pages it describes — and a sitemap that is wrong is worse than none, because it teaches a crawler to distrust the signal.
Structured data is a set of claims about what is on a page. Implemented per page it drifts immediately; implemented from the content model it is generated, consistent, and correctable in one place.
On a WordPress site large enough to have a search problem, the problem is almost never a setting. It is the URL structure, the archives nobody chose, or a template defect affecting every page of a type at once.
A forum's value is a decades-deep archive of discussion. Its search problem is that the archive is also its largest source of thin, paginated and near-duplicate pages — and the two facts pull in opposite directions.
A decline has a cause and the cause is not always available to you. This work establishes which one it is, fixes the part that is yours, and says plainly when the rest is not something anybody can recover.
A news sitemap is small software that most teams write once and then stop watching. We build it against the publish event, validate it before it deploys, and monitor whether the articles inside it are actually being found — because a news entry is only useful for the two days Google allows it.
A newsroom produces content faster than any search engine will fetch it. The engineering question is not how to rank articles — it is how to make sure the ones you published this morning are found while they still have a news life left.
Discover has documented eligibility requirements and an unpublished ranking system. The technical work is real and it is bounded — and the part that determines traffic is not the part anyone can change.
Client-rendered content is not automatically invisible, and server-rendered content is not automatically visible. The gap between what a browser shows and what a crawler receives has to be measured, and then closed at the layer that caused it.
Decoupling changes who renders the page. That single change determines what a crawler receives, and it quietly removes several things a conventional CMS provided without anyone deciding to give them up.
Most post-migration traffic loss is not bad luck. It is a predictable set of decisions — URL mapping, redirect architecture and cutover sequencing — each of which has a right answer that is easier to choose before launch than after.
A multilingual site is a set of decisions about identity: what a locale is, where it lives, and which version should be served to whom. hreflang is the last of those and the only one that is a tag.
On a large site the diagnosis is often the easy part. The work is getting a fix through a release cycle you do not control, owned by a team that does not report to you, on a platform you may not be able to modify at all.
A marketplace's inventory is created and removed by other people, changes daily, and generates URL space in combinations nobody chose. That is a different problem from a site whose content is authored.
Analytics reports what happened in a browser. A server log reports every request, including the ones that were never rendered — which is where crawl problems live and where no other instrument looks.
The reports are a search engine's account of what it found, and most of what they contain is either informational or already correct. The work is telling the actionable findings from the ones that should be left alone.
A retainer is not a project with a longer calendar. It is capacity, a queue and a cadence — and the useful thing to establish before buying one is how the work is chosen, and what it is not.
Work where this cluster was the substance of the engagement.
Since 2019, Soludome has managed infrastructure and platform operations for one of Spain's largest online communities. The work covers server and performance optimisation, CDN architecture, load balancing and site security under sustained traffic.
A stockbroking platform publishing at news velocity was losing search visibility to problems that had nothing to do with content quality. Two workstreams ran in parallel: sustaining a high-volume editorial output across business and market categories, and diagnosing the technical faults — a domain safety flag, recurring server errors, and a metadata defect on a templated page type — that were suppressing how much of that output search engines could actually reach.
An established community platform had accumulated three separate problems that compounded each other: page loads that had degraded with growth, search visibility that had not kept pace with the community's authority, and a security posture that had not been revisited as the platform's profile grew. The engagement addressed all three concurrently.
A large marketplace platform in the United States was experiencing critical downtime from compounding traffic and application faults. Soludome analysed requests through the web application firewall, identified and blocked the DDoS patterns, and repaired a third-party payment flow that allowed links to be generated repeatedly without authentication. Server load fell and platform performance improved after the work.
A platform that had previously ranked well had declined through a combination of technical and on-page problems: nearly ninety percent of the site failed Google's Core Web Vitals assessment, server response times were high, and metadata and content signals needed work. The engagement addressed those constraints together.
The disciplines support each other. A platform that cannot stay up cannot be crawled reliably, and a search problem frequently turns out to be an infrastructure problem.
Building AI into systems that have to work in production.
Keeping high-traffic systems fast, available and secure.
Building and running the systems editorial teams actually publish on.
Describe what the system is doing. Working out which discipline applies is part of the diagnosis, not something you should have to guess.