Skip to content
VERQEN — home

Service 02 · Service

Technical SEO for sites where mistakes are expensive.

On a large site, a single canonical rule or a misconfigured parameter can quietly remove thousands of pages from search. We find those decisions, prove what they are costing, and fix them with your developers.
Request a technical reviewSee how we work
Timeline
Audit 2–3 weeks; implementation depends on your release cycle
Starting from
From $2,500 for a focused fix project
Shape
Audit, then a scoped implementation project or ongoing programme
Deliverables
8 items

The problem

Search engines cannot reliably reach or understand your important pages.

Technical SEO problems rarely look dramatic. Impressions flatten, a template stops being indexed, a set of category pages gets treated as duplicates. Nothing breaks visibly, so nobody escalates it — while the pages that should be earning traffic are invisible.

You probably recognise some of these

  • Search Console shows large “Crawled – currently not indexed” or “Discovered – currently not indexed” groups.
  • Important pages have no internal links pointing at them.
  • Content is visible in the browser but missing from the raw HTML response.
  • Filter and parameter URLs are consuming crawl budget.
  • Impressions are flat while you keep publishing.

Who needs this

Is this for you?

  • Sites with thousands of URLs, filters, facets or large product catalogues
  • JavaScript-heavy sites where rendering is uncertain
  • Multi-market or multi-language sites with hreflang complexity
  • Companies with developers who need exact, testable requirements — not advice
  • Teams who have been told “it is a technical SEO problem” and want it specified properly

Why it happens

What usually causes it

  1. Default CMS or framework behaviour that was never reviewed against a crawl.
  2. Canonical and noindex rules applied template-wide without checking which URLs they hit.
  3. Faceted navigation that generates near-infinite crawlable combinations.
  4. Client-side rendering for content that search engines need in the initial response.
  5. Internal linking driven by design layout rather than page importance.
  6. Migrations and redesigns that changed URL structure without a value-weighted redirect map.

Scope, in detail

What exactly we check

Not a category list — the actual checks. If something is not on here and you need it, say so and we will tell you whether it fits the scope.

Crawlability

  • Full crawl with rendering enabled
  • Status codes and redirect chains
  • robots.txt directives and blocked resources
  • XML sitemap accuracy and coverage
  • Crawl budget waste on parameters and duplicates
  • Orphan and low-link-depth pages

Indexation

  • Canonical strategy consistency
  • Accidental noindex and nofollow
  • Duplicate and near-duplicate clusters
  • Parameter handling
  • Pagination strategy
  • Faceted navigation rules

Rendering

  • HTML response versus rendered DOM diff
  • JavaScript-dependent content and links
  • CSS and API dependencies for critical content
  • Server-side rendering / static generation coverage
  • Soft 404s produced by client-side routing

Architecture

  • Internal link graph and link equity distribution
  • Site depth for commercially important pages
  • Hub and cluster structure
  • Breadcrumbs and navigation consistency
  • URL structure and stability

Performance & markup

  • Core Web Vitals — LCP, INP, CLS — field and lab
  • TTFB and server response consistency
  • JavaScript and CSS weight, third-party scripts
  • Image weight and formats
  • Structured data validity and appropriateness

International

  • hreflang implementation and reciprocity
  • Country and language targeting
  • Duplicate content across markets
  • Currency, locale and redirect behaviour

Deliverables

What you actually receive

Every important issue arrives in the same format: problem, evidence, why it matters, root cause, solution, exact actions, owner, priority and measurement.
Request a technical review
  • Technical audit with every issue expressed as Problem → Evidence → Impact → Exact change
  • Developer-ready tickets: what to change, where, and how to test it
  • Indexation strategy — what should be indexed, what should not, and why
  • Internal linking plan targeting the pages that carry commercial value
  • Redirect and canonical rules written as rules, not as spreadsheets of guesses
  • Rendering requirements for the templates that matter
  • QA checklist so your team can verify each fix independently
  • Re-crawl and validation after implementation

Process

How the work runs

Each step has an exit condition. We do not move on because time passed.

  1. Baseline

    Crawl the site with rendering on, pull Search Console and analytics, and identify which URLs actually carry traffic, conversions and revenue.

    • Rendered crawl
    • GSC export
    • Value-weighted URL list

  2. Diagnose

    Find where crawling, rendering, indexing or internal linking breaks down for those specific URLs — not for the site in general.

    • Crawl vs index vs traffic
    • DOM diff
    • Link graph

  3. Specify

    Write the exact change for each issue: file, rule, template, expected output, and how to test it. Your developers should not have to interpret anything.

    • Tickets
    • Acceptance criteria
    • Test steps

  4. Implement

    Either your team implements against the spec with us reviewing, or we work directly in the codebase where that is appropriate and access allows.

    • Staging first
    • Code review
    • Rollback plan

  5. Validate

    Re-crawl, re-test rendering, watch Search Console coverage and confirm the change did what it was supposed to — including checking for side effects.

    • Re-crawl
    • Coverage watch
    • Side-effect check

What we need from you

Access and data

We ask for read access only, and only for what the question needs.
  • Google Search Console (all properties, read access)
  • GA4 (read access)
  • Staging environment access, if there is one
  • CMS or framework details and a developer contact
  • Server logs, where available — they answer questions nothing else can
  • Existing crawler exports and any prior audits

Measurement

What results can be measured

Agreed before the work starts, so nobody argues about the definition afterwards.
  • Indexed valuable pages versus total valuable pages
  • Coverage report movement by category
  • Non-brand impressions and clicks on target templates
  • Crawl requests spent on valuable versus wasted URLs (from logs)
  • Average link depth for commercial pages
  • Core Web Vitals pass rate on revenue templates

Afterwards

What happens when the project ends

You keep the specifications, the QA checklist and the indexation strategy. A monthly programme is the option if you want new templates and releases reviewed before they ship, which is far cheaper than fixing them after.
How scoping and pricing works

Why trust us

How we keep ourselves honest

  • Every recommendation is testable. If we cannot tell you how to verify it, we have not finished writing it.
  • We work with your developers in their process, not around them.
  • We do not recommend deleting or de-indexing anything without showing you the data first.
  • High-impact changes — canonicals, redirects, pruning — always get human review before delivery.

Honest limitations

What this service will not do

Stated up front, because finding out later is worse for both of us.
Technical SEO removes barriers. It does not create demand: if nobody searches for what a page offers, fixing indexation will not make it earn traffic.
Some questions cannot be answered without server logs. If you cannot provide them, we will tell you which conclusions stay unconfirmed.
We will not implement changes directly in production without a staging environment and a rollback plan.

Quick answers

Technical SEO & Search Growth in nine questions

The same facts, stated plainly. Useful if you are skimming, and useful to any system trying to understand what we actually offer.
What is this service?
Make sure search systems can crawl, render, index and understand the pages that carry your revenue.
Who is it for?
Sites with thousands of URLs, filters, facets or large product catalogues; JavaScript-heavy sites where rendering is uncertain; Multi-market or multi-language sites with hreflang complexity; Companies with developers who need exact, testable requirements — not advice; Teams who have been told “it is a technical SEO problem” and want it specified properly.
What problem does it solve?
Search engines cannot reliably reach or understand your important pages.
What do you check?
6 areas covering crawlability, indexation, rendering, architecture, performance & markup, international.
What do you deliver?
Technical audit with every issue expressed as Problem → Evidence → Impact → Exact change; Developer-ready tickets: what to change, where, and how to test it; Indexation strategy — what should be indexed, what should not, and why; Internal linking plan targeting the pages that carry commercial value; Redirect and canonical rules written as rules, not as spreadsheets of guesses; Rendering requirements for the templates that matter; QA checklist so your team can verify each fix independently; Re-crawl and validation after implementation.
How long does it take?
Audit 2–3 weeks; implementation depends on your release cycle
How much does it cost?
From $2,500 for a focused fix project. Audit, then a scoped implementation project or ongoing programme.
What access is needed?
GSC, GA4, staging access, developer contact; server logs if available
What happens after?
You keep the specifications, the QA checklist and the indexation strategy. A monthly programme is the option if you want new templates and releases reviewed before they ship, which is far cheaper than fixing them after.

Questions

Questions about seo & search growth

Something else? hello@verqen.com

Evidence and further reading

Worked investigations and working notes on this subject.

Related services, problems and industries

The problems this service usually solves, and where we see them most often.