The rule: you read the code, you don't write it
SEO is filed under marketing and diagnosed like engineering. That's the whole tension, and it resolves into one practical rule: you need to read a site well enough to say precisely what's broken, why it matters, and what it's costing. You almost never need to write the fix.
The job is closer to a building surveyor than an architect. You walk the structure, find the damp, and write a report a builder can act on without guessing. You don't lay bricks and nobody expects you to.
Roughly a third of the discipline is technical, and that third caps everything else. A brilliant content plan on a site that returns 500s under crawl load produces exactly nothing, and no amount of writing fixes it.
The non-negotiable list
This is the floor. Below it you'll misdiagnose things, and misdiagnosis in SEO is expensive — you spend three months solving the wrong problem and only find out in month four.
| What | Why it decides whether you rank | How deep to go |
|---|---|---|
| HTML source | Titles, canonicals, meta robots, headings, <a href> links and alt text all live here. If you can't read view-source, you're guessing. | Read it fluently. Write it almost never. |
| HTTP status codes | 200, 301, 302, 304, 404, 410, 429, 500 and 503 each tell a crawler something different. A 302 where a 301 belongs makes a migration slower and much harder to debug. | Know those nine cold, and where to see them live. |
| robots.txt and meta robots | Blocking a URL in robots.txt stops Google reading the noindex on that page — so it can stay indexed indefinitely. This exact mistake is everywhere. | Understand precedence, not syntax trivia. |
| XML sitemaps | Submitted versus indexed is one of the fastest diagnostics available to you, and it's free. | Be able to generate one and audit what's in it. |
| Redirects | Chains, loops and redirects to irrelevant pages wreck more migrations than any other single cause. | Map them before anyone touches a replatform. |
JavaScript: the line between reading and writing
This is where "is SEO an IT skill" stops being an argument. Modern sites build much of their content in the browser, and Google renders JavaScript in a second pass that is neither instant nor guaranteed for every page on every site. If your content only exists after that pass, you're carrying a risk a plain HTML site simply doesn't have.
What you must be able to do yourself
- Compare raw HTML (view-source) with the rendered DOM (DevTools Elements) and say what's missing from the first.
- Use Search Console's URL Inspection to see the HTML Google actually rendered, not the one you hoped for.
- Recognise links that aren't links — a
<div onclick>or a router-only navigation is invisible as a link, however it behaves for humans. - Spot content that only appears after a click, a scroll, a tab switch or a login.
What you hand to a developer
A specific ask in their language, not a lecture about crawl budget. Server-render or pre-render these route templates. Make navigation use real <a href> elements. Put the canonical, title and meta robots in the initial HTML response. Stop lazy-loading the primary content.
You don't need to write React. You need to know what to ask for, why, and how to verify it shipped. JavaScript SEO covers the mechanics.
Servers, CDNs and log files — where mid becomes senior
The next tier up is infrastructure, and it's the cleanest dividing line between an SEO who executes a checklist and one who diagnoses a site nobody else can figure out.
- Time to first byte and caching. A slow server response caps every downstream speed metric. Knowing whether the fix is caching, hosting or application code is worth far more than knowing the metric names.
- CDN and bot-protection rules. Security rules blocking Googlebot are a real and recurring cause of sudden deindexing. Somebody tightened a firewall rule on a Friday; the rankings went on Monday.
- Log files. Server logs are the only place you can see what Googlebot actually requested, how often, and what it got back. On large sites this is how you find crawl waste that no crawler tool will show you.
- Staging and environments. A staging site indexed by accident, or a
noindexshipped from staging into production, is a career-defining afternoon. Ask how the two environments differ before you need to know.
What a non-technical SEO can still do extremely well
Plenty, and it's worth saying clearly because the technical crowd is loud. Some of the most commercially valuable SEO work involves no code at all.
- Keyword and intent research — deciding what to build is worth more than building it well.
- Content strategy, briefs and editing, which is still the largest block of hours on most retainers.
- Internal link architecture, which is a structural skill rather than a coding one.
- Digital PR and link earning, which is closer to journalism than to engineering.
- Local SEO and Google Business Profile work, where the technical ceiling is low and the commercial return is fast.
- Measurement, reporting, and the conversation where you explain to a founder what actually happened.
How to learn the technical half, in order
All of this is free apart from your time, and none of it needs a course. It's also the fastest-moving part of the wider timeline in how hard SEO is to learn — the technical half rewards deliberate practice more than any other part of the job.
- Read a page's source and say what's wrong with it. Ten sites, ten minutes each. Title, canonical, meta robots, H1, and whether the navigation links are real links.
- Learn nine status codes and where to watch them. Chrome DevTools' Network tab shows you every request. Follow a redirect chain live and it stops being abstract.
- Crawl a small site. Screaming Frog's free tier covers 500 URLs, which is enough to find your first orphan page and your first redirect loop.
- Break things deliberately on a test site. Add a
noindex, block a folder inrobots.txt, then watch Search Console react over the next fortnight. Fear of the technical side dies here. - Read one real log file, even a single day of it. Watching Googlebot spend its requests on faceted URLs nobody wants explains crawl budget better than any article, including this one.
- Learn to write the ticket, not the code. URL pattern, expected behaviour, current behaviour, priority, and how you'll verify it. Being easy for developers to work with is a technical skill in its own right, and it's the one nobody teaches.