Technical SEO
Work on the layer that decides whether your site can be crawled, rendered and indexed: performance, JavaScript, URL architecture and crawl budget.
Request an initial diagnosis- 15
- years working alongside engineering teams
- 6
- senior specialisms inside the team
- 48 h
- to reply, at most
Brands that have trusted Laika
One of these situations may well sound familiar.
You're going to scale a large site
You have hundreds of thousands of URLs, Google crawls what doesn't matter and the pages that sell take weeks to refresh.
You're going to launch a JavaScript-rendered site
The framework is decided and nobody has checked what the crawler sees when content depends on the client.
You're going to ask engineering for technical work
You need tickets written in their language, with evidence and priority, so your team knows what to execute.
You're going to tackle performance and Core Web Vitals
The tool flags a hundred red warnings and it takes judgement to separate the three that move the business.
You're going to clean up facets, filters and parameters
The CMS generates endless combinations, canonicalisation contradicts itself and the same content competes with itself.
You're going to take the site international
New languages or markets, where the technical model, hreflang and canonical paths decide whether each version reaches its country.
Four fronts always reviewed, plus whatever your stack calls for
These four are in every project, though the weight of each depends on the technology. A thousand-URL WordPress isn't reviewed like a headless site with a hundred thousand SKUs.
Crawling and indexing
So the crawler reaches what matters and stops burning budget on what doesn't sell.
See the detail
- Robots.txt: server response, file type and rules that are actually active
- XML sitemaps: response, values, coverage and consistency with what's indexable
- Meta robots and indexing directives page by page
- Parameters, facets and CMS filters: what gets crawled and what gets cut
- Internal linking: links to 3xx, 4xx and 5xx, and nofollow usage
- Crawl budget with server logs when access is available
Rendering and devices
So what the crawler sees matches what a person sees, on mobile, with nothing extra to execute.
See the detail
- Response to the Googlebot Mobile user-agent and status codes per template
- Viewport tag configuration and its attributes
- Served HTML versus rendered DOM on key templates
- Content and links that depend on JavaScript to exist
- Render-blocking resources and deferred loading above the fold
- Render strategy: server, prerender or hybrid, with what it means for engineering
Architecture and the on-page layer
So every URL is unique, canonical and labelled for what it actually answers.
See the detail
- URL structure and canonical paths: protocol, trailing slash, casing and duplicates
- rel=canonical setup and contradictions with sitemap, pagination and filters
- Status codes on content pages and 404 page configuration
- Titles, meta descriptions and heading hierarchy per template
- Structured data: what applies, what can be validated and what adds nothing
- Insecure resources and mixed links that break page trust
Performance and Core Web Vitals
So performance is worked by real impact, not to raise a tool's score.
See the detail
- TTFB and server response time on the highest-traffic templates
- Server compression (Gzip, Brotli, Deflate) and cache policy
- Weight and images: compression, declared dimensions and next-gen formats
- Minification and JavaScript/CSS code that's never actually used
- Visual stability: what causes layout shifts
- Prioritisation: the three changes that move the metric, the rest in the queue
And what each project adds
Depending on technology, catalogue size and markets, specific fronts are added that wouldn't make sense everywhere.
International and hreflang
Domain or subdirectory model, hreflang attribute, regional settings and real localisation of content and tags per language.
Log analysis
When server access exists: what Google really crawls, how often, and what stays out.
Client-rendered sites
SPA, headless and JavaScript frameworks: what's served, what hydrates and what never reaches the index.
Large-scale e-commerce
Catalogues with thousands of SKUs: pagination, facets, out-of-stock and product variants.
Who does it?
Senior profiles who sit with engineering without an interpreter. Whoever diagnoses is who explains it and who reviews it once shipped.
Why Laika?
Technical work only counts if your team can execute it.
Finding a hundred problems is easy. Deciding which matter, writing them for engineering and verifying afterwards is what changes the outcome.
We talk with engineering, not about it
Half of technical work gets lost in translation. We sit with your CTO and write tickets the way their team expects them.
Our own protocol, not a tool report
Thirty-five items always reviewed, with human judgement on top to decide which of them matter on your site.
We prioritise by business, not traffic-light colour
A red warning can be irrelevant and a green one can be costing you traffic. We order by real impact.
Seniority at the table from day one
Whoever diagnoses is who explains it to you and who reviews it again once it's shipped.
Frequently asked questions
Can you talk directly to our CTO?
That's what we prefer. Half of technical work gets lost in translation.
How long until I see results?
The first findings and decisions land within weeks. Impact on visibility and revenue depends on your platform and your team's implementation speed: on mid-sized projects we usually talk about three to six months for solid movement.
I worked with another agency and it didn't work. Why now?
What usually fails is judgement, not effort: tasks get executed without deciding what matters. Before proposing anything we review your data, and if the problem isn't visibility we'll tell you, even if it means not selling the project.
Tell us what's holding you back
With the technology, the size of the site and what you've already tried, we can tell you where we'd start. We look at your project before proposing anything.
Is a technical problem stuck?
We look at it, prioritise it and write it up so your team can execute it.
We look at your project before proposing anything. Reply within two working days at most.
Talk to us about your site