Technical SEO for Developers: 12 Things to Build In From Day One
Technical SEO for developers: 12 things to build into a new website from day one, from rendering and redirects to sitemaps, schema and Core Web Vitals.
Freelance full-stack developer
- Published
- Reading time
- 9 min
In this post7
Technical SEO for developers comes down to one job: making sure search engines can crawl, render and index every page you ship. Most of it costs next to nothing as part of the first build, and a lot once it has to be retrofitted into templates, URLs and server config. These are the 12 things I think every developer should build into a new website, each with a quick way to check it.
I build websites for businesses myself, so read this with that in mind. It's written for developers and for the people who hire them.
The short answer: 12 items, ranked by the cost of fixing them later
| # | What to build in | Cost to fix later |
|---|---|---|
| 1 | Server-rendered HTML | High |
| 2 | Clean, stable URLs | High |
| 3 | Real status codes | Medium |
| 4 | Redirects managed in the system | Medium |
| 5 | One URL per page (canonical) | Medium |
| 6 | Titles, descriptions and share images per page | Low |
| 7 | A generated XML sitemap | Low |
| 8 | Robots and noindex controlled per environment | Low to fix, costly to miss |
| 9 | Structured data generated from data | Low |
| 10 | Images, fonts and scripts within Core Web Vitals | Medium |
| 11 | Semantic HTML and crawlable links | High |
| 12 | Language versions with hreflang | Medium |
My rule of thumb: anything marked high gets decided before the design turns into code. If you haven't chosen how the site should be built yet, start with deciding between building it yourself, no-code or hiring a developer.
Rendering, URLs and status codes (items 1-4)
These four decide whether search engines can read your pages at all, and the first two are tied to framework and routing choices that are expensive to change later.
Rendering, URLs and status codes
- 1. Server-rendered HTML: Google renders JavaScript, but as a separate step after crawling. Its own JavaScript SEO guide still recommends server-side rendering or pre-rendering, partly because not all bots can run JavaScript. Check: open view-source. If headings and body copy are in the raw HTML, you're fine.
- 2. Clean, stable URLs: /services/websites, not /page?id=42. Lowercase, one trailing-slash rule, enforced by the router. Faceted filters on a shop shouldn't generate thousands of crawlable combinations. Every URL you change later needs a redirect. Check: can you tell what a page is about from its URL alone?
- 3. Real status codes: A missing page returns 404 (or 410 if it's gone for good), never a friendly error page with a 200. Otherwise empty pages can get indexed as soft 404s, a classic problem in client-side routed apps. Check: run
curl -Iagainst a URL that doesn't exist and read the first line. - 4. Redirects managed in the system: Editors should be able to add 301s from the admin without a deploy, and the system should prevent chains where A points to B, which points to C. Google recommends keeping redirects for at least a year after a site move. Check: ask where redirects live and whether 404s are logged.
WordPress and most modern frameworks render on the server by default, so item 1 usually breaks in single-page apps and home-grown setups. I cover those trade-offs in WordPress vs a custom-built website. Replacing a site that already has traffic? Then redirects matter most, and they get a full walkthrough in migrating a website without losing SEO.
Search signals: canonicals, metadata, sitemaps and robots (items 5-8)
Cheap to build, but only reliable when generated from your content.
Search signals
- 5. One URL per page (canonical): The same page is often reachable with and without www, over http or with tracking parameters. Pick one version, 301 the rest and output a self-referencing canonical tag on every page. Check: try your domain with and without www. Both should land on the same address.
- 6. Titles, descriptions and share images per page: Editable fields for title, meta description and Open Graph image, with sensible fallbacks when they're empty. Check: does your CMS expose these fields, and what renders when they're blank?
- 7. A generated XML sitemap: Rebuilt automatically when content is published or deleted, using absolute URLs. Google's sitemap documentation says Google ignores priority and changefreq but uses lastmod when it's consistently accurate. So lastmod should be the real modification date, not the build time. Check: open /sitemap.xml and look for your newest page.
- 8. Robots and noindex controlled per environment: Staging sits behind a password or sends noindex. A robots.txt file alone won't do it, because Google's robots.txt introduction states that it doesn't keep a page out of Google. Drive the setting from an environment variable so it can never ship to production. Check: search the production HTML for "noindex" on launch day.
Item 8 is, in my view, the most dangerous on the list because nothing looks broken. Visitors use the site normally while search engines have been told to stay away.
With a headless CMS, the frontend owns titles, sitemaps and canonicals, built from CMS data. Settle who builds what when you choose a headless CMS.
Structure and speed (items 9-12)
The last four help search engines understand each page and keep it fast on a real phone.
Structure and speed
- 9. Structured data generated from data: JSON-LD that describes the page as an Article, Product or LocalBusiness, plus breadcrumbs, generated from the same data the page renders so prices and addresses never drift. Check: run a page through Google's Rich Results Test.
- 10. Images, fonts and scripts within Core Web Vitals: The targets are LCP within 2.5 seconds, INP of 200 milliseconds or less and CLS of 0.1 or less, measured at the 75th percentile of page loads according to web.dev. That means responsive images with explicit dimensions, self-hosted fonts and a budget for third-party scripts. On EU sites, test the consent banner too: injected late, it can hurt both LCP and CLS. Check: read the field data in PageSpeed Insights, not just the lab score.
- 11. Semantic HTML and crawlable links: One h1, a logical heading order, real links and buttons. The same Google guide notes that Google only discovers links that are a-elements with an href, so navigation built on click handlers may be invisible. Semantic markup is also the base for accessibility, which the European Accessibility Act now requires of many online shops in the EU. Check: tab through the page. If the keyboard reaches every link, the markup is usually right.
- 12. Language versions with hreflang: European businesses often need two or three languages. Give each version its own URL (/en/, /de/), connect them with reciprocal hreflang tags and an x-default, and don't auto-redirect on browser language, which can hide versions from Googlebot. Check: does each language version have its own URL, and do they reference each other?
Item 10 is the one that slips after launch, as chat widgets, tag managers and consent tools pile up. It's rarely the framework's fault. I wrote up how I handled speed and SEO on my own site in how I built simonij.com.
What technical SEO won't fix
Technical SEO removes obstacles; it doesn't create demand. A technically flawless site with nothing people search for still gets no traffic. On a small site built with Squarespace, Wix or Webflow, the platform handles most of this list (sitemaps, HTTPS, status codes and metadata fields), so don't pay a developer for technical SEO there. Spend the budget on content.
The list matters most on a custom build, a redesign of a site that already ranks, or a site with hundreds of pages, such as a shop or catalog, where one template bug hits every page at once.
For launch day itself, work through the website launch checklist.
Next steps
- Put the 12 items in the project brief, so they're part of the quote rather than a change request.
- Ask your developer how each one is handled: which package, which setting, where in the admin.
- Check items 1, 3, 5 and 8 on staging and again on launch day.
- Add the site to Google Search Console the day it goes live.
If you need a new website built, see how I work on custom websites for businesses. You deal directly with the developer writing the code, and you own that code from day one.
Frequently asked questions
Is technical SEO the developer's job or the marketer's?
Mostly the developer's, because it lives in templates, routing and server config. Marketers usually own keyword research, content and links, and they're often the first to spot problems in Search Console. A shared checklist works well: the developer builds the items in, the marketer monitors them after launch.
Can technical SEO be fixed on an existing site?
Yes, most of it. Metadata, sitemaps, structured data and redirects are usually manageable retrofits. Rendering and URL structure are harder, because changing them can mean rebuilding large parts of the site and redirecting every old URL. Start with the Page indexing report in Search Console to see which problems actually cost you traffic.
Does a single-page app hurt SEO?
Not necessarily, but it raises the risk. Google renders JavaScript in a separate step, and other crawlers may not run it at all. Each view also needs a real URL, status code and proper links. For public content, server-side rendering or static generation is the safer default. Keep client-side rendering for logged-in app screens.
Is Next.js or Laravel better for technical SEO?
Both can deliver everything on this list. Next.js renders on the server by default with the App Router, and Laravel serves server-rendered HTML through Blade. If a Laravel project uses React through Inertia, server-side rendering has to be enabled separately. Problems usually come from how a framework is used, not from which one you pick.