Great SEO takes a lot more than keyword research and a few content tweaks.
The recommendations that actually move rankings tend to be the technical ones, like cleaner markup, faster pages, and fixing the things that search engines and crawlers simply can't read, and almost all of those live in code.
That's the part nobody warns you about, and it's where a lot of good SEO work quietly grinds to a halt.
When we audit a site, the findings are rarely the hard part. The hard part is what happens after we hand them over. The fixes with the biggest upside are usually the ones that need a developer to implement, which means they're also the ones most likely to sit in a backlog for six months while the quick content edits get ticked off first.
SEO strategy is only ever worth as much as the slice of it that actually ships. So when we say a great SEO team needs a developer, we don't mean someone you can email once a quarter. We mean someone who's part of the team, who understands what you're trying to do and why.
Here's where that support ends up mattering the most.
Whenever we put together a set of SEO recommendations, a good chunk of them end up being changes to the site template and design. Sometimes it's something fairly contained, like reworking heading tags or adjusting CSS.
Other times it's bigger, like adding a functional UX element or restructuring a template so there's actually room for the content a page needs in order to rank.
An SEO who knows their way around your CMS can handle some of this on their own, and plenty do. But a developer who genuinely understands why the change is being made will move faster through it, and they'll catch the things that a content-only editor never sees coming.
Just as importantly, a developer will tell you when not to do something.
Honestly, half the value of having one on your SEO team is the recommendation they talk you out of, because they can see the blocker or the dependency or the side effect that just isn't visible from the front end of the site.
That second opinion is what keeps a well-meaning "fix" from quietly breaking something else down the line.
It's also the point where web design and SEO stop being two separate conversations, because more often than not, the design decision and the ranking decision are the same decision, made in the same template, by the same person.
Structured data is a perfect example of how technical SEO can look simple right up until the moment it isn't. Adding schema so your pages become eligible for rich results in Google can genuinely be as easy as flipping a toggle in your CMS, and for some sites that's all it takes.
For plenty of others, that's where the trouble starts.
If working on websites for as long as we have has taught us anything, it's that default settings rarely behave the way you'd expect them to. You flip that "enable" button and suddenly you're staring at a wall of validation errors with no obvious cause, no clear way to isolate the problem, and no fix available anywhere inside the CMS itself.
That's exactly the moment you want a developer who can go in, adjust the defaults, write a bit of custom code, and keep your markup valid as the standards keep shifting underneath you.
Rich results can make a real difference to how your listing looks and performs in search, but only when the markup is actually correct, and getting it correct is a development job more often than not.
You can't really improve what you're measuring incorrectly, which is why tracking deserves more care than it usually gets.
The moment you want to do anything beyond the out-of-the-box setup, whether that's filtering out logged-in users on a SaaS platform or tracking custom events properly, it helps enormously to have a web developer on hand.
Google's analytics tooling will get most people most of the way there, but customising and correctly implementing the tracking code is precisely where data tends to go wrong, and bad data is genuinely worse than no data at all, because you'll go ahead and trust it.
Google Tag Manager has been a real gift for teams who can't touch the site's code directly, and there's a surprising amount you can do in it without ever involving a developer.
Even so, Tag Manager still needs dev help around the edges, and getting your reporting and analytics set up properly from the start is far cheaper than trying to untangle months of misattributed data after the fact.
The biggest payoff of having a developer on your SEO team really shows up on new builds.
Once someone has implemented the same handful of SEO requests enough times, they start building those considerations in by default, on their own projects, without anyone having to ask.
A site that's built with technical SEO in mind from day one saves you a small fortune in retrofitting later, and it gives you a head start on search visibility from the moment it goes live.
The alternative is a pattern we run into constantly. A gorgeous new site launches, everyone's thrilled, and then the SEO team spends the next three months filing tickets to fix foundational things that really should have been baked in from the beginning.
Retrofitting SEO onto a finished build is always slower and more expensive than doing it properly the first time, and it never comes out quite as clean either.
Experimentation is one of the best ways to learn, and we'd never tell anyone to stop poking at their own site.
The question worth asking first is a simple one: if you break something, can you put it back? If you push a change and accidentally take the site down, are you confident you can recover it?
We've had more than a few clients come to us because they'd caused a serious problem editing something they didn't fully understand. Sometimes it's a five-minute fix, and everyone has a laugh about it. But for a larger, revenue-driving site, the cost of downtime adds up frighteningly fast, and "let me just try this" can turn into a very expensive afternoon.
Having a developer involved is the difference between a confident experiment and a gamble with your storefront, and that peace of mind is worth more than it looks on paper.
Here's the part that didn't exist at all when we first wrote this post.
A growing share of discovery now happens inside AI tools and AI-generated answers, which is the same shift we dug into in our piece on zero-click and AI search, and the AI crawlers behind those answers come with a hard technical limitation that most marketers have never been told about, which is that they don't run JavaScript.
In an analysis of over 500 million crawler requests, Vercel and Merj found that the major AI crawlers, including OpenAI's GPTBot, Anthropic's ClaudeBot, and PerplexityBot, simply fetch your raw HTML and move on. They don't wait around for scripts to render, and they don't come back for a second attempt.
Google's crawler still renders JavaScript, but these AI crawlers do not, and that distinction matters more than it sounds.
If your content is loaded client-side, the way a great many modern JavaScript sites work, then those tools land on what is effectively an empty page where your product copy and your reason to be cited are supposed to be.
You can be ranking beautifully in Google and still be completely invisible to ChatGPT, and most teams have no idea it's happening. The fix sits squarely with a developer. Server-side rendering, or otherwise making sure your important content exists in the initial HTML response rather than being painted in afterward, is what puts you back on the menu for AI answers. It isn't a plugin you install or a box you tick. It's an architecture decision, and it's probably the clearest example yet of why adapting your search strategy for AI runs straight through your development team.
About the only lever here that doesn't need a developer is your robots.txt, where you get to decide which AI bots are allowed to crawl you in the first place, and really, that's the through-line of everything above.
The technical foundations of search keep shifting, and every single time they do, the work of keeping up lands on someone who can write code.
A smaller boutique agency can give you a lovely personal engagement and a lot of specialised expertise, but it often comes without much of a bench to lean on.
A full-service team gives you specialists across different disciplines and the reassurance that someone can actually fix things when they go sideways.
Our own clients get a lot of value out of having our development team right there to build and implement code, make site changes, and get every SEO recommendation properly shipped instead of stalled in a queue somewhere.
That, in the end, is the whole point. SEO doesn't fail because the recommendations were wrong. It fails in the gap between the recommendation and the live site, and closing that gap is exactly what developer support is for.
If that gap sounds familiar, let's get to work.
Does SEO need a developer?
Not for everything, but for the work that matters most, yes. Content and keyword changes can often be handled in a CMS, but technical fixes like template changes, structured data, custom tracking, site speed, and server-side rendering really need someone who can safely edit code. Those also tend to be the highest-impact recommendations of the lot.
Does SEO require coding?
Day-to-day SEO doesn't require you to write code yourself, and plenty of excellent SEOs aren't developers. Implementing the technical recommendations does require code, though, which is why the best results tend to come from an SEO team and a developer working closely together rather than either one going it alone.
What does a developer actually do for SEO?
They implement template and markup changes, fix crawl and indexing issues, improve site speed and Core Web Vitals, set up accurate tracking, and handle server-side rendering so both search engines and AI crawlers can read your content. In short, they ship the technical fixes that an SEO audit turns up.
Can I do technical SEO without a developer?
You can handle the basics through your CMS and tools like Google Tag Manager, but you'll hit a ceiling fairly quickly. The fixes that move rankings the most, and the ones that keep you visible as search keeps changing, generally need development support to implement correctly and safely.