Web Development and SEO: Why It Starts Before the First Line of Code

A site goes live. Everyone’s proud of how it looks. And then… nothing. Weeks go by, traffic trickles in at a pace that would embarrass a brochure, and by the third month it finally clicks: search engines barely know the site exists.

Hey, my name is Roman Makuev. I lead the SEO and design team at Neon, and after fourteen years and more projects than I can neatly count, I ended up building my own SEO analysis tool, Algorithm, to make the work faster and more precise instead of guessing.

I’ve watched this play out more times than I’d like to admit. The frustrating part is that it’s almost never a design problem or a content problem in isolation. It’s a timing problem. Most teams treat SEO as something you bolt on after launch, when in reality the decisions that matter most — the ones that are painful and expensive to undo — all happen before anyone writes code.

When you build with SEO baked in from the start, you skip the bulk of the cleanup work that otherwise eats three to six months after launch. You also dodge the structural rewrites that quietly kill ranking potential. A site planned for search from day one indexes faster, climbs higher, and holds its position more reliably than one retrofitted in a panic. This is the approach my team takes on every build — we treat web development and SEO as one process rather than two phases, and we even write the first batch of blog content during development, scored by our own analyzer before a word goes live.

How Web Development and SEO Fit Together

People tend to picture SEO and web development as two separate jobs handed to two separate teams: the developers build the thing, then the SEO people show up afterwards to “optimize” it. That hand-off is exactly where most ranking potential leaks away. In practice, SEO and web development are the same job viewed from two angles — every meaningful SEO decision is a build decision, and most build decisions quietly carry SEO consequences whether anyone meant them to or not.

Think about what actually gets decided in code. How the site is structured. How URLs are formed. Whether pages render in a way a crawler can read. How fast the thing loads on a mid-range phone. What markup describes the content to a machine. None of those are “add it later” tasks — they’re architecture, and architecture is the developer’s domain. By the time an SEO specialist is brought in post-launch to fix them, the cheap window has closed and you’re paying for rewrites instead of decisions.

The point isn’t that developers must become SEO experts or vice versa. It’s that the two have to share a plan before anyone writes code — agree on the structure, the URL patterns, the rendering approach, the content the site needs to own. Get that right and SEO stops being a costly cleanup project and becomes a property of a well-built site.

The Three Windows Where SEO Actually Gets Decided

It helps to stop thinking of SEO as a task and start thinking of it as a set of decisions spread across the project. There are three windows where those decisions land.

Before development. This is where your keyword strategy (the “semantic core”) and your site architecture get locked in. Change your mind later and the cost grows exponentially — you’re not editing a page, you’re re-pouring the foundation.

During development. URL patterns get encoded. You choose how pages render. Meta tags, schema, the whole technical skeleton — it all gets wired up here.

Before launch. Everything gets tested and audited. A problem caught in this window is a quick fix. The same problem caught a month after launch is an emergency, complete with re-crawling and lost ground.

Building the Semantic Core (Before You Commit Code)

The semantic core is just the structured answer to one question: what is this site actually about, and what are people searching for when they need it? Here’s the process I use.

1. Market intelligence. Look at what competitors rank for, find the gaps they’ve left open, and spot seasonal patterns. Semrush, Ahrefs, AnswerThePublic and Google Trends each show you a different slice of this.

2. Collect keywords. Pull together your primary topics (around 5–15 core themes), the long-tail variations that reveal real intent, and the question-shaped queries — the “how to,” “what is,” “where to find” stuff. That last bucket matters more than ever in the AI-search era.

3. Cluster and tag by intent. Group keywords that mean roughly the same thing, then label each cluster by what the searcher actually wants: to learn (informational), to find a specific site (navigational), to compare (commercial), or to buy (transactional). Intent is the part most people skip, and it’s the part that makes everything downstream easier. Loose clustering — lumping “best X” with “what is X” — quietly wrecks your architecture, because you end up building one page for two different intents and it ranks for neither. We built our own clustering engine specifically to keep intent boundaries clean at scale, but the principle holds regardless of tool.

4. Map topics to the site. Every cluster should correspond to a real area of the site. This is the step that quietly dictates your URL structure and navigation, because it tells you which pages need to exist and how they relate.

5. Write it down. Build one reference sheet — topic pillar, primary keyword, search volume, difficulty, long-tail variations, target URL, intent — and share it with everyone touching the project. A semantic core that lives in one person’s head isn’t a strategy, it’s a liability.

Site Architecture: Make It Easy to Crawl, Easy to Trust

Your structure decides whether search engines can efficiently reach your content, which pages accumulate authority, and how quickly new pages get indexed. A few principles I won’t budge on:

• Keep the hierarchy shallow and logical. Three to five primary categories, subcategories under those, individual pages under those. Aim to keep everything within three clicks of the homepage.
• Keep URLs flat. Three levels deep, max. /resources/blog/seo-techniques is fine. /resources/guides/content/seo/techniques/best-practices is a maze.
• Organize by theme, not by whim. Build pillar pages that cover a major topic comprehensively, then support each with cluster pages that go deep on subtopics. Interlink them deliberately.
• Leave no page orphaned. Every page worth having should be reachable from navigation, footer, or an internal link. If nothing points to a page, search engines treat it like it doesn’t exist.

A visual sitemap drawn before development becomes your blueprint. It’s worth the half hour.

URL Structure and the Technical Foundation

A few URL habits that pay off forever:

• Separate words with hyphens (on-page-seo, never on_page_seo)
• Skip special characters and stray parameters
• Keep them descriptive but short — three to five words
• Mirror your site hierarchy in the path
• Decide the strategy before you build, because changing URLs later means a pile of 301 redirects and the inevitable mistakes that come with them

And the technical checklist that should be in place at launch:

robots.txt — Block the stuff crawlers don’t need (admin, staging, internal search results) while keeping important resources open. Point to your sitemap here. One addition for 2026: decide deliberately how you treat AI crawlers like GPTBot, ClaudeBot, PerplexityBot and Google-Extended. Allowing them is how your content becomes eligible to be cited inside AI answers.

sitemap.xml — List every page that matters, auto-generated through your CMS so it stays current.

Canonical tags — Self-referencing on unique pages, so you don’t accidentally split authority across duplicate URLs.

HTTPS — Non-negotiable. SSL certificate, clean HTTP→HTTPS redirects, and a Strict-Transport-Security header.

Mobile — Responsive is the floor, not a feature. Test on real devices: content reachable without zooming, tap targets at least 48px. Over half of all search traffic is mobile.

Core Web Vitals — These are confirmed ranking factors, and several numbers people memorized a few years ago are now wrong. Here’s the current state:

The INP one trips people up most. If your checklist still references “First Input Delay under 100ms,” it’s two years out of date — Chrome dropped FID support entirely, and INP is stricter because it watches every interaction across a session, not just the first click. One nuance: these are measured from real users via the Chrome User Experience Report (field data), at the 75th percentile — not from a one-off lab test on your laptop.

And there’s a quieter reason to care, beyond the raw ranking factor: speed moves money. In a joint Deloitte/Google study across dozens of brands, a 0.1-second improvement in load time lifted retail conversions by around 8% and travel-booking conversions by around 10%.

Schema Markup: Talking to Machines in Their Own Language

Schema turns your plain text into structured data that search engines (and increasingly, AI models) can read without guessing. It’s what powers rich results, featured snippets, and the answers that show up in voice and AI search. The types worth implementing on most sites:

• Organization (homepage) — name, logo, contact, social profiles. The backbone of a knowledge panel.
• Article / BlogPosting (posts) — headline, publish date, author, image.
• FAQPage (high-intent pages) — question-and-answer pairs that make you eligible for snippet placement.
• BreadcrumbList (every page) — communicates hierarchy and tends to improve both click-through and crawl efficiency.

Use JSON-LD. It’s clean, it lives separately from your HTML, and it’s the format Google explicitly prefers. Here’s the shape of it:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "SEO Starts Before the First Line of Code",
  "datePublished": "2026-06-08",
  "author": {
    "@type": "Person",
    "name": "Roman Makuev",
    "url": "https://seo-algorithm.com/"
  },
  "image": "https://example.com/cover.png"
}
</script>

One rule that trips people up: your schema must match what’s actually visible on the page. Don’t mark up an FAQ that isn’t there. Before launch, run everything through Google’s Rich Results Test.

The Part the Old Playbooks Skipped: Optimizing for AI Search

Here’s what’s genuinely new and what most older “SEO before development” guides don’t mention at all. Search isn’t just ten blue links anymore. A growing share of queries get answered directly — inside Google’s AI Overviews, or inside ChatGPT, Perplexity, Gemini and Claude — without the user ever clicking through. If your content can’t be read, understood, and cited by those systems, you’re invisible in a channel that’s quietly eating a chunk of your traffic.

Translation: ranking #1 no longer guarantees you a seat in the AI answer. Being cited is becoming its own discipline, and it rewards depth and source-worthiness over pure position. The reassuring part: there’s no separate dark art here. Google itself published a guide in May 2026 confirming that strong, traditional SEO — original content, a crawlable and well-structured site, a clear user experience — is still the foundation for showing up in AI Overviews and AI Mode.

What that layer actually involves:

• Answer the question early. AI systems extract facts. Put a clear, self-contained answer in the first hundred words or so, and phrase headings as the questions people actually ask.
• Make authority verifiable. This is where E-E-A-T stops being a buzzword and becomes a technical requirement. AI systems cite authors with a real digital footprint — a LinkedIn profile, mentions in the Knowledge Graph, external references.
• Lean even harder on structured data. LLMs rely on schema more than traditional crawlers do — it’s how they reliably extract facts instead of inferring them.
• Offer something that isn’t a commodity. When AI can summarize the generic version of any topic in two sentences, the only content worth citing is content that says something the model couldn’t generate on its own.

Information Gain: The New Standard for Indexing

If you take one idea from this whole piece, take this one.

Topic authority in 2026 is awarded for added value, not volume. Google has gotten ruthless about excluding rehashes of whatever’s already in the top 10. If an article doesn’t bring new data, a fresh case, a different angle, or a connection between ideas that wasn’t already out there, it doesn’t earn authority — it can sit at zero no matter how long or well-formatted it is. The term for this is Information Gain: how much new you added to the index, not how many words you produced.

This has a hard consequence most people underestimate: Google now evaluates the quality of your domain as a whole. A blog full of thin, rehashed, AI-spun articles published “for volume” doesn’t just fail to rank itself — it drags down the trust of your entire domain, including your service and money pages. I’ve audited sites where the services pages were genuinely good but couldn’t rank because a neglected blog of 60 low-effort posts had poisoned the host-level signals.

This is exactly why my team writes real, scored content during development rather than spinning up filler later. Before anything publishes, we run it through our own analyzer — it flags AI-pattern density, checks whether the piece actually adds information versus paraphrasing competitors, and grades it against the genre. A page that scores as a rehash never goes live, because one weak cluster can cost the whole domain. The tooling is ours (Algorithm), but the discipline is portable: measure information gain before you publish, not after you’ve tanked.

Every piece is scored for information gain before it goes live — a rehash never publishes.

On-Page: Titles, Descriptions, Headings, Links

Your title tag is the one piece of on-page real estate that earns or loses the click before anyone reads a word, so I treat it as a tiny ad rather than a label. The pattern I keep coming back to is the keyword first, then the value, then a modifier — something like On-Page SEO Checklist: 10 Actionable Techniques [2026]. Keep it under sixty characters or so, put the part that makes someone curious up front, and never reuse the same title twice across the site.

Meta descriptions are a different job. They won’t move your rankings on their own, but they decide whether the listing looks worth clicking, so I write them like a one-line pitch: the benefit, a quick why, and a nudge to act, all inside roughly 155–160 characters with the main keyword sitting in there naturally.

Headings are where a lot of sites quietly trip themselves up. One H1 per page, carrying the primary keyword, and then H2s and H3s to break the thing into a shape that actually mirrors how the content flows. Jumping straight from an H2 to an H4 because it “looks right” confuses screen readers and crawlers alike.

Then there’s internal linking, which I think is the most underused tool on this list. The model that works is pillar-and-cluster:

Pillar: "Content Marketing Strategy: Complete Guide"
├── Cluster: "Content Marketing for SaaS"
├── Cluster: "Content Calendar Creation"
└── Cluster: "Measuring Content ROI"

That web of links is how you tell a search engine you’ve actually covered the ground instead of just brushing against it. A few things make it work in practice: anchor text that describes where the link goes (not “click here”), the important links sitting high on the page, restraint, and the habit of pointing your strongest existing pages at anything new.

Measuring What You Built

Once a month is plenty. I’d watch organic traffic, the average position of your target keywords, click-through rate, how many pages are actually sitting in the index, and your Core Web Vitals baselines. And there’s one more worth adding lately: whether the AI tools mention you at all. The low-tech way to check is to open ChatGPT, Gemini, Perplexity and Copilot and ask them the questions your customers ask — then see if your name comes up, and whether what they say about you is even right.

For the rest, Search Console and Analytics 4 do most of the heavy lifting and they’re free. Add a rank tracker and a speed tool so you can see the gap between your lab numbers and what real users experience. The loop itself is simple, and the discipline is in actually running it. Make your changes, then leave them alone for four to six weeks before you decide whether they worked.

Rough Timelines, by Project Size

None of this is a rule, but after enough projects the shapes are pretty consistent.

The Non-Negotiables

If your budget or patience only stretches to a few things, these are the ones I’d fight for. Get your semantic core down before development starts. Build an architecture that’s logical and shallow enough for a person to navigate without thinking. Make the mobile experience genuinely good, tested on a real phone rather than a resized browser window. Hit the current Core Web Vitals thresholds, not the ones from two years ago. And never let a rehash go live — because one weak cluster can pull the whole domain down with it.

Once those are handled and you’ve got room to push further, that’s when the rest earns its place: full schema coverage (Organization, BreadcrumbList and FAQ at the very least), tidy URLs and meta tags, the AI-search layer, an author profile that actually proves your E-E-A-T, and the unglamorous habit of revisiting all of it after launch instead of declaring victory.

Common Mistakes

Most of the failures I see come from the same short list. Someone treats SEO as a thing you do after launch. The URL structure ends up six levels deep and impossible to unwind later. The mobile version “mostly works,” which is another way of saying it mostly loses. The checklist still optimizes for FID, a metric that no longer exists. The blog gets stuffed with AI-spun filler to hit a word count, and quietly drags the whole domain’s trust down with it. The articles are competent rehashes of the existing top 10 with nothing new added. And — the one that hurts most because it’s so avoidable — the site launches with no analytics or Search Console in place, so for the first crucial weeks nobody can see anything at all.

Your Action Plan

This week, just carve out two hours and sit with it. Spend an hour on the semantic core, half an hour sketching the architecture, and half an hour settling the technical approach. That’s it — the point is to make the expensive decisions on purpose rather than by accident.

Over the month, lock down the architecture and URL structure, draft your title and meta-description templates so writers aren’t reinventing them every time, and get Search Console, Analytics and your rank tracker set up before you actually need the data.

While you’re building, keep SEO inside the workflow instead of off to the side. Work through the technical checklist, test on a phone constantly, keep an eye on Core Web Vitals — and write your launch content now, scored for information gain, rather than promising yourself you’ll backfill it later. (You won’t.)

Right before launch, run a proper audit, fix anything critical, confirm the tracking is actually firing, and validate your schema. Then for the first week after you go live, watch it closely; after that, settle into the monthly rhythm. If carrying all of this yourself isn’t realistic, that ongoing work is exactly what an experienced SEO team exists to handle, so you can keep your attention on the product.

FAQ

Is SEO really cheaper if you do it during development?

Much cheaper. Fixing it on a site that’s already live usually means three to six months of cleanup plus the structural rewrites nobody enjoys — changing URLs, building redirect chains, waiting on re-crawls. The decisions you make before any code exists, like architecture and the semantic core, cost almost nothing to set and a small fortune to unpick.

Is FID still a Core Web Vital?

No — it was retired back in March 2024 when Interaction to Next Paint took over, and Chrome has since dropped FID support entirely. What you want to hit now is INP under 200ms, LCP under 2.0s (Google tightened that in 2026), and CLS under 0.1.

Does ranking #1 get me into Google’s AI Overview?

Not on its own anymore. As of early 2026, only about 38% of AI Overview citations come from top-10 pages, down from 76% a year before. What earns the citation is depth on the topic, an author Google can verify, and content that adds something — not the ranking position by itself.

Can a bad blog hurt my service pages?

It can, and this catches people out. Google increasingly judges quality at the level of the whole domain, so a blog packed with thin or AI-spun posts can pull down the trust signals across the entire site and hold back your commercial pages even when those pages are perfectly good.

What is Information Gain?

It’s a way of asking how much new your content brings to the index — original data, real experience, an angle nobody’s published — rather than how many words it runs to. In 2026 that’s what builds topic authority, and it’s why straight rehashes of the top 10 tend to get left out.

Final Thought

The sites that end up dominating search almost never got there by luck. They got there because someone decided, before a line of code was written, how the thing would be structured, which topics it would own, and how information would move through it. That kind of discipline compounds quietly — a small edge at the foundation turns into a wide gap a year down the line.

Your development stage is the most leverage over search visibility you will ever have. So use it. Plan the structure, claim your topics, check the information gain before you hit publish, and build for both the humans reading and the machines now reading on their behalf. Start before the first line of code — everything else grows out of that.