If you build websites, at some point an SEO consultant will send you a list of "technical fixes". Some will look obvious, some will look strange, and at least one will conflict with how your app renders pages.

This guide explains what an SEO consultant actually does, what they'll ask developers for, and how to get the collaboration right, ideally before launch rather than after traffic drops.

TL;DR

• An SEO consultant diagnoses why a site isn't getting the search traffic it should, then prioritises and guides the fixes across technical, on-page and off-page work.
• For developers, the overlap is mostly technical SEO: rendering, status codes, canonicals, metadata, sitemaps, structured data, performance and internal linking.
• The best results come when SEO requirements are part of the build spec, not a post-launch ticket list.

What an SEO consultant actually does

An SEO consultant's job is to answer three questions about a site, in this order:

1. Can search engines access it? Crawling, rendering, indexing.
2. Do the pages match what people search for? Keywords, intent, content, metadata.
3. Is the site trusted enough to rank? Links, mentions, reputation.

That maps to the three branches of SEO:

If you want a deeper explanation of how these fit together, I've written about the difference between on-page and off-page SEO and where technical SEO sits.

A typical engagement looks like this:

1. Audit: crawl the site, review Search Console, analyse logs and benchmark competitors.
2. Prioritise: rank issues by impact and effort. Not everything in an audit tool's "errors" list matters.
3. Spec the fixes: write requirements developers can actually implement.
4. Validate: check fixes in staging and production.
5. Measure: track indexing, rankings, traffic and conversions over the following weeks and months.

What an SEO consultant will ask developers for

These are the requests that come up on almost every project.

1. Server-rendered or pre-rendered HTML for important content

Google can render JavaScript, but rendering happens later than crawling, and other crawlers (including many AI crawlers) may not execute JavaScript at all. If your main content, links or metadata only appear after client-side rendering, expect the consultant to ask for SSR, SSG or pre-rendering for indexable pages.

Quick test: curl the page and check whether the important content is in the raw HTML.

curl -s https://example.com/pricing | grep -i "<title>\|<h1\|rel=\"canonical\""

2. Correct HTTP status codes

The classic problem is the soft 404: a "not found" message rendered with a 200 status, common in SPAs. Search engines treat these as low-quality pages.

3. One canonical URL per page

Duplicate URLs split signals: ?utm_source=, trailing slash vs no slash, uppercase paths, sort parameters. Expect requests to:

• Add a self-referencing canonical on every indexable page
• 301 redirect variants to one format (e.g. always lowercase, consistent trailing slash)
• Keep tracking parameters out of internal links

<link rel="canonical" href="https://example.com/services/technical-seo/" />

4. Editable, unique metadata per page

Templates should allow a unique <title> and meta description per page, with sensible fallbacks. In Next.js (App Router), for example:

// app/services/[slug]/page.tsx
import type { Metadata } from "next";

export async function generateMetadata(
  { params }: { params: Promise<{ slug: string }> }
): Promise<Metadata> {
  const { slug } = await params;
  const service = await getService(slug); // your data source

  return {
    title: service.seoTitle ?? service.name,
    description: service.seoDescription,
    alternates: { canonical: `https://example.com/services/${slug}/` },
  };
}

The key requirement: content editors must be able to change titles and descriptions without a deploy.

5. XML sitemaps that reflect reality

• Only canonical, indexable URLs that return 200
• Generated automatically as pages are added or removed
• lastmod updated only when content actually changes, not on every build
• Referenced in robots.txt

User-agent: *
Disallow: /search
Disallow: /*?sort=

Sitemap: https://example.com/sitemap.xml

6. Structured data

Consultants will often ask for JSON-LD on key templates: Organization, BreadcrumbList, Article, Product, FAQPage, LocalBusiness. The rule is simple: only mark up what's visible on the page.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://example.com/" },
    { "@type": "ListItem", "position": 2, "name": "Services", "item": "https://example.com/services/" }
  ]
}
</script>

Validate with Google's Rich Results Test and the Schema.org validator.

7. Performance and Core Web Vitals

Google's Core Web Vitals thresholds for a "good" experience are:

• LCP (largest contentful paint): 2.5 seconds or less
• INP (interaction to next paint): 200 milliseconds or less
• CLS (cumulative layout shift): 0.1 or less

Typical asks: compress and size images, set width/height on media, defer non-critical JavaScript, cut third-party scripts and cache aggressively.

8. Crawlable internal links

Navigation and in-content links should be real <a href="..."> elements. Links that only work through onClick handlers or JavaScript routing without an href may not be followed by crawlers.

<!-- Crawlable -->
<a href="/services/seo/">SEO services</a>

<!-- Not reliably crawlable -->
<span onclick="router.push('/services/seo/')">SEO services</span>

The pre-launch SEO checklist for developers

Most expensive SEO problems are introduced at launch or during a migration. Run this before go-live:

• Staging is blocked from indexing (auth or noindex), and production is not
• robots.txt on production doesn't block the whole site (it happens more than you'd think)
• Every indexable page returns 200 with server-rendered main content
• Unique <title>, meta description, H1 and canonical on every template
• 301 redirect map from old URLs to new URLs (for migrations)
• XML sitemap generated and referenced in robots.txt
• Custom 404 page returns a real 404 status
• Structured data validates
• Core Web Vitals checked on key templates (mobile first)
• Analytics and Search Console set up and verified

When does a project actually need an SEO consultant?

You can handle the basics yourself on small sites. A consultant earns their fee when:

• You're migrating a domain, CMS, framework or URL structure. This is where sites lose years of rankings overnight.
• Traffic dropped after an update or a release and nobody knows why.
• The site is large: thousands of pages, faceted navigation, multiple languages.
• Search is a major revenue channel, and you need someone accountable for organic growth.

How developers and SEO consultants work best together

• Get involved early. SEO requirements belong in the technical spec, not a post-launch Jira backlog.
• Ask for impact. A good consultant can explain why a fix matters and what it's expected to change.
• Push back on noise. Audit tools flag hundreds of "issues". Many don't matter. Ask which ones affect indexing or revenue.
• Share access. Search Console, server logs and staging environments make diagnosis far faster.

Wrapping up

An SEO consultant isn't there to sprinkle keywords on pages. The job is diagnosing why a site isn't earning the search visibility it should, prioritising the fixes that matter, and making sure they're implemented correctly. For developers, that mostly means clean rendering, correct status codes, one URL per page, good metadata, accurate sitemaps and fast pages.

Get those right in the build and SEO becomes far cheaper for everyone.

I'm Mirza Usman Ghani, an SEO and paid media consultant. I work with developers and businesses on technical SEO, site migrations and search growth through my SEO consultant services. This article was written with AI assistance and reviewed by me for accuracy.