SEO Consultant or Web Developer? Who You Need and When

Why do people confuse the two roles?

Both work on your website. Both talk about titles, speed and structure. Both use words like "optimise". So it's easy to assume they're interchangeable, and to wonder why you'd pay two people when one seems to do the job.

They're not interchangeable, and treating them as if they were is one of the most common reasons small business SEO stalls. A developer is a builder. An SEO consultant is closer to a surveyor and a planner. One asks "how do I make this work?" The other asks "what should this be, and will anyone find it?"

What does each role actually do?

A web developer designs and builds the technical parts of a website: templates, features, integrations, hosting set-up, performance and security. They turn requirements into working code. A good one cares about clean, maintainable work and about how the site behaves for users.

An SEO consultant looks at how the site performs in search and why. They study what customers search for, how Google crawls and indexes the site, where visibility is lost and what to change. They prioritise fixes, plan content and structure, set up measurement and brief developers and writers.

Overlap exists, but it's partial

Both care about speed and clean markup. Neither replaces the other's core skills.

What does Google say?

Google's hiring guidance, Do you need an SEO? Tips for hiring an SEO, last updated on 5 June 2026, notes that hiring an SEO is most valuable during a site redesign or new site launch, though a good SEO can also improve an existing site. It also says small local businesses can often do much of the work themselves, starting with Google's SEO Starter Guide.

Those two points together are useful. They suggest that the best time to involve an SEO is when structural decisions are being made, which is exactly when developers are working. And they remind you that not every business needs a consultant at all.

Planning beats rescue

Building SEO thinking into a redesign costs far less than repairing a launch that ignored it.

Which problems need a developer, and which need an SEO?

A useful way to decide is to look at the problem, not the title. Some issues are fundamentally technical. Others are fundamentally about strategy and judgement.

Most real problems have both.

Which problems are mainly developer territory?

Slow pages caused by heavy scripts, unoptimised images or poor hosting. Broken layouts on mobile. Template-level bugs that output wrong canonical tags or noindex directives. Redirect rules at server level. Security and HTTPS configuration. JavaScript frameworks that don't render content for crawlers. Platform limitations and plugin conflicts.

An SEO can spot these, because they affect search visibility, but fixing them takes code and platform knowledge. The consultant's role is to define the fix precisely and check the result. A good diagnosis follows a structured technical SEO audit checklist.

The consultant's job on these

Evidence, impact, a clear description of the desired behaviour and a test that proves it's fixed.

Which problems are mainly SEO territory?

Choosing which searches to target and which page should answer each one. Deciding what content to create, merge or remove. Planning site structure and internal linking. Optimising a local profile and managing reviews. Diagnosing a traffic drop. Setting up meaningful measurement. Judging competitors and opportunities. And deciding priorities across all of it.

A developer can implement the output of those decisions, but shouldn't be expected to make them. Asking a developer to "do the SEO" without direction often produces generic changes, such as meta tags on every page, that miss the real issues.

Judgement is the scarce skill

Anyone can change a title tag. Knowing which titles matter, and what they should say, is the expertise.

Which problems need both from the start?

Redesigns and migrations. International sites with hreflang. Ecommerce platforms with filters and parameters. Sites that rely heavily on JavaScript. Anything where URL structure, templates and content plans interact. In these cases, involve both early, with a shared plan.

The guide to a website migration SEO checklist shows how much of a migration's success depends on joined-up work between the two.

When should you hire an SEO consultant first?

If you don't yet know what's wrong, a diagnosis comes before a build. Spending developer time on guesses is expensive, and the consultant's value is in making the guesses unnecessary.

Several situations point that way.

Which situations suggest starting with the consultant?

Traffic or enquiries have fallen and nobody knows why. Pages aren't being indexed. Rankings stagnate despite effort. You're planning a redesign or migration and want to protect visibility. You're unsure which services or locations to prioritise. You've inherited a site and don't know its history. Or you have a long list of ideas and no way to rank them.

An independent SEO audit produces a prioritised list of what to fix, in what order, with evidence. That list is exactly what a developer needs to work efficiently, and it saves paying for changes that won't help.

Start small

A fixed-fee diagnostic limits risk and gives you something concrete to hand to a developer.

What should you expect from the consultant at this stage?

A clear diagnosis of the main issues, a ranked list of recommendations with expected impact and effort, a plan for sequencing the work and developer-ready briefs for the technical items. Honest notes on uncertainty and dependencies. And a measurement plan so you can see whether the changes worked.

If the output is a stack of tool reports with no priorities, you haven't got what you paid for. The guide to what to expect in the first 30 days with an SEO consultant describes what good looks like.

When should you hire a developer first?

Sometimes the site itself is the obstacle. If it's broken, painfully slow or built on something unfit for purpose, no amount of strategy will help until it's fixed.

Recognise those cases.

Which situations suggest starting with the developer?

The site is down or unreliable. It's hacked or insecure. It doesn't work on mobile. It has no CMS and every change needs code. The hosting can't cope with traffic. The platform is unsupported. Or you need new functionality, such as booking or ecommerce, that doesn't exist yet.

In those cases, get a developer to stabilise or rebuild, but still involve an SEO in the plan. A rebuild that ignores URL structure, redirects, templates and content can throw away years of visibility. The guide to Core Web Vitals for business websites helps frame what good performance means for the brief.

Bring the SEO into the brief

Give the developer a short list of requirements: clean URLs, crawlable links, fast templates, proper status codes, structured data and a redirect plan.

What should you tell a developer about SEO?

That crawlers need real links and rendered content. That each page needs a unique, descriptive title and heading. That URLs should be clean and stable. That canonical tags and directives must be correct. That performance matters. That structured data should match visible content. And that changes to live URLs need redirects.

Most developers appreciate clear requirements, especially if you explain why. Treat it as a brief, not a lecture, and offer to review the staging site before launch with a checklist.

How should the two work together?

The relationship between SEO and development is where results are won or lost. Good outcomes come from clear handoffs and mutual respect.

A few habits make a big difference.

What does a good brief look like?

One problem per ticket. A one-sentence description of the issue. The affected pages or templates, with examples. The current behaviour and the desired behaviour. Why it matters, in plain words. How to check it's fixed. Priority and any deadlines. Screenshots or exports as evidence.

An example: "Service pages output a canonical pointing to the services index. Change the template so each service page's canonical points to its own URL. Test: view source on /services/example/ and confirm a self-referencing canonical." That's specific, testable and quick to act on.

Avoid jargon without context

If a term might be unfamiliar, explain it briefly, or link to documentation. Developers value clarity.

How do you keep the work moving?

Agree a shared priority list, so developers aren't pulled in different directions. Hold a short regular check-in. Test changes on staging before release. Ask developers to flag anything that conflicts with other work. Record every change in a log. And name one person on your side who owns SEO delivery.

When the consultant and developer talk directly, with you in the loop, things move faster than when everything passes through you. Encourage it, and make sure decisions and approvals are clear.

Respect each other's constraints

Developers have release cycles, testing and risk. SEOs have evidence and deadlines. A little understanding on both sides avoids friction.

What does it cost, in time and money, to use both?

Budgets are real. Most small businesses can't afford a full-time developer and a full-time SEO. Fortunately, you don't need them.

Flexible arrangements fit most situations.

How do small businesses usually structure it?

Many use a consultant for a fixed-fee audit and roadmap, then a few hours of developer time, from a freelancer, an agency or the site builder's support, to apply the fixes. Others use a retainer with a consultant for ongoing strategy and monitoring, and call in a developer for specific projects. Some hire a developer who has SEO awareness and use a consultant for periodic reviews.

The right mix depends on how much change your site needs and how much you can implement yourself. For a platform with a visual editor, you may be able to apply many recommendations without a developer at all.

Ask for estimates in hours

Ask the consultant to estimate developer effort for each recommendation, so you can plan realistic costs. The guide to hourly, retainer and project pricing explains how SEO work is priced.

How do you avoid paying twice for the same thing?

Define who's responsible for what in writing. Share the audit with the developer before work starts. Agree acceptance criteria. Test changes. And avoid asking both to "look at speed" or "fix SEO" without clear scope, because they may duplicate or conflict.

Keep a single list of issues and owners, updated as work progresses. It's the simplest way to prevent confusion, double work and dropped tasks.

What about platforms, site builders and agencies?

Many small sites are built on platforms such as WordPress, Shopify, Wix, Squarespace or Webflow. Each shapes what can be changed, and by whom.

The platform affects the answer.

How does the platform change who you need?

On a hosted site builder, much of the technical work, such as hosting, security and basic performance, is handled by the platform, and many SEO changes are done in settings. You may need a consultant more than a developer. On a custom build or a heavily customised CMS, the developer is central, because many changes require code.

Know what your platform allows. Some limit control over URLs, canonicals, structured data or server rules. A consultant who knows the platform can tell you what's possible, and whether a workaround or a move is needed.

Ask about limitations early

If the platform can't do something important, you want to know before you plan around it.

What about web agencies that offer SEO?

Many web design agencies include some SEO, from basic set-up to full services. Quality varies. Ask what's actually included, who does it and how it's measured. Make sure the SEO work involves more than installing a plugin and filling in meta tags.

For a major project, consider having an independent SEO review the plan, because an agency isn't always best placed to judge its own SEO work. The comparison between delivery models is explained in the guide to SEO consultant vs agency vs in-house team.

What mistakes cause SEO and development to fail together?

Most failures aren't about skill. They're about process. A few patterns recur.

Knowing them helps you avoid them.

Which mistakes are most common?

Treating SEO as a last-minute checklist before launch. Hiring a developer to do SEO without direction. Hiring an SEO and then not giving them access or developer time. Sending vague requests, such as "improve speed". Changing things on the live site without testing. Not recording changes. And having nobody own the relationship between the two.

Another is the launch surprise: a redesign goes live with new URLs, no redirects and a blocked robots.txt because nobody checked. The fix is a pre-launch SEO review and a post-launch monitoring plan.

Put SEO on the launch checklist

Redirects, robots.txt, canonicals, sitemaps, tracking and indexing checks belong in every release plan.

How do you prevent them?

Involve the SEO at the start of any project that changes templates, URLs or navigation. Write requirements in plain language. Give the consultant staging access and a way to test. Hold a short pre-launch review. Monitor after launch. And keep a change log that both can read.

If a change has unclear SEO consequences, pause and ask. A few minutes of conversation is cheaper than weeks of recovery.

How do you choose the right people?

Whether you're hiring a consultant, a developer or both, the same principles apply: check evidence, ask good questions and start small.

A few specific tips help for this pairing.

What should you look for in a consultant who works with developers?

Evidence of writing clear, testable briefs. Comfort discussing technical issues without hiding behind them. Respect for developers' constraints. A habit of verifying fixes. And honesty about what they do and don't know. Ask for a sample ticket or brief, and look at how specific it is. The questions to ask an SEO consultant before hiring include prompts for this.

Check how they'd work with your developer: would they join a call, review staging, write acceptance criteria and test the result?

A good sign

A consultant who asks about your developer's availability and release process before promising dates.

What should you look for in a developer who works with SEO?

Willingness to learn what a change is for. Care about clean markup, performance and crawlable structure. A process for testing and rollback. Openness to a staging review by the SEO. And honesty about what the platform can and can't do.

Ask how they handle redirects, URL changes and templates, and whether they've worked with an SEO before. A developer who has will often have good instincts. One who hasn't can still do excellent work with clear briefs.

Trial the pairing on one small project

A single, defined fix, such as correcting canonicals or improving the speed of one template, shows how well the two work together before you commit to something large.

What does a worked example look like?

A story brings the roles to life. This one is hypothetical, built from typical patterns, with illustrative details.

It follows a small online retailer.

What was the situation?

A small online shop's enquiries from search had fallen after a redesign by a freelance developer. The owner assumed the developer should "fix the SEO". The developer added meta descriptions and a plugin, and nothing improved. The owner then considered hiring an SEO but worried it would duplicate the developer's work.

An independent SEO audit found the real causes: the new category templates output canonical tags pointing at the homepage, old URLs weren't redirected and a filter plugin generated thousands of near-duplicate pages. None of those was fixed by meta descriptions.

The diagnosis

Three template and configuration problems that needed developer skills, but could only be identified and prioritised by someone looking at search data.

How did they work together?

The consultant wrote three tickets, each with evidence, the desired behaviour and a test. The developer fixed the canonical template, added a redirect map and limited the filter plugin's crawlable links. The consultant checked on staging, then after release, and monitored indexing and impressions. They agreed a short check-in every two weeks.

Within a couple of months, category pages returned to the index and enquiries recovered. Neither person could have achieved it alone: the developer didn't know what to fix, and the consultant couldn't write the fix. The owner's contribution was to bring them together, name one person to coordinate and keep the change log. That's the pattern to copy. Decide what needs diagnosing and what needs building, hire accordingly and make sure the two talk to each other.

The takeaway

The consultant decides what and why. The developer decides how and builds it. You make sure the handoff between them is clear, tested and recorded.

How do you run a redesign so SEO and development stay in step?

Redesigns are the moment when the two roles collide most often, and when the stakes are highest. A new design can be handsome and still erase years of visibility. A shared plan prevents it.

Break the project into stages, and make sure each has a role for both people.

What happens before design and build?

The SEO audits the current site: which pages earn traffic and links, which queries bring visitors, what structure works and what doesn't. They produce an inventory of URLs, a list of pages that must keep their addresses or be redirected and a set of requirements for the new design. The developer reviews the requirements for feasibility, flags platform constraints and proposes how to meet them.

Agree the URL structure early. Changing URLs is the single biggest risk in a redesign, and it should be a deliberate choice backed by a redirect map, not a side effect of a new template.

The inventory is gold

A spreadsheet of current URLs, their traffic, links and purpose becomes the basis for the redirect map and the launch checklist.

What happens during build and testing?

The developer builds on a protected staging site. The SEO reviews it against the requirements: crawlable links, correct canonicals, titles and headings, structured data, status codes, performance and mobile behaviour. Issues go into tickets with clear acceptance criteria. The redirect map is tested before launch.

Make sure staging is blocked from search engines with a password, not only a robots.txt rule, and that nothing from staging, such as noindex settings, is copied to production by mistake. The step-by-step sequence is in the guide to a website migration SEO checklist.

What happens at and after launch?

Launch day has a checklist: remove staging blocks, confirm robots.txt and sitemap, test redirects, check key templates, verify tracking and submit the new sitemap. Afterwards, the SEO monitors indexing, errors, impressions and rankings against the pre-launch benchmark, and the developer is on hand to fix issues quickly.

Plan a freeze on unrelated changes for a few weeks, so that any problem can be traced. Document every change after launch. A well-run launch feels uneventful, which is exactly the goal.

How do you keep the relationship healthy over the long term?

Projects end. Sites don't. Ongoing collaboration needs routines that keep the work visible and the priorities clear.

A few lightweight habits are enough.

What does a sensible monthly rhythm look like?

A short call or written update between the SEO and the developer, with the owner copied in. Review the open tickets, agree priorities for the month and note blockers. The SEO shares findings from Search Console and crawls. The developer shares upcoming releases that might affect templates or URLs. Both update the change log.

Keep a shared board of tasks, with owners, status and dates. It removes the need for lengthy meetings and makes progress visible to everyone, including people who don't speak either specialist language.

Reserve time for maintenance

Technical SEO is partly maintenance. Budget a few developer hours each month for fixes that come out of monitoring, rather than treating every one as a project.

How do you handle disagreements?

They'll happen. A developer may think a recommendation is risky or low value. An SEO may think a delay is costing visibility. Resolve them with evidence: the data behind the recommendation, the risk and effort, the alternatives and the cost of waiting. Involve the owner when priorities conflict, because the decision is ultimately a business one.

Agree the rule in advance: SEO recommends and explains, development assesses and implements, and the owner decides when they disagree. Clear roles stop small disagreements becoming standoffs.

Keep it respectful

Both disciplines are skilled. Assume good faith, and ask for reasons rather than assigning blame.

What if you only have a small budget and no developer?

Plenty of small businesses have neither a retained developer nor much to spend. The question then isn't "who do I hire?" but "how do I get the most important things done with what I have?"

A pragmatic approach works.

Which fixes can you do yourself?

On most site builders and CMS platforms, you can edit page titles, headings, copy, image alt text and internal links yourself. You can set up Search Console and analytics, claim and complete your Business Profile, ask for reviews and publish useful content. Google's own guidance says small local businesses can often do much of the work themselves, starting with the SEO Starter Guide.

Use a consultant's audit as a to-do list. Work through the items you can do in the editor, and flag the ones that need code. That keeps developer hours, and your costs, to a minimum.

Make a two-column list

Left column: things I can do in the editor. Right column: things that need a developer. The right column is your developer brief.

How do you buy developer time sensibly?

In small, defined chunks. Ask your site builder's support team, a freelance developer or a local agency for an hourly or fixed-price quote for a specific list of fixes. Give them the consultant's tickets, with evidence and acceptance criteria. Ask for a test plan, and check the results yourself.

Avoid open-ended retainers for a site that needs a few targeted changes. A one-off project, followed by a light maintenance arrangement, usually fits a small business better. And keep records of every change, so the next person can see what was done.

Don't skip the testing

A fix that isn't verified isn't finished. A short check on the live site catches most mistakes.

When does it make sense to invest more?

When the site is a primary source of revenue, when you're planning growth or a redesign, or when a problem is clearly beyond what you can solve in the editor. At that point, a proper audit, a prioritised roadmap and a reliable developer relationship pay for themselves. The wider comparison of delivery models is in the guide to SEO consultant vs agency vs in-house team.

Start where the biggest gains are, invest steadily and keep the focus on outcomes: more of the right people finding the business, and more of them getting in touch.