Technical SEO checklist for developers: 8 choices that make or break your rankings

Technical SEO is not a marketing party, these are choices you make as a developer in code, hosting and configuration. This technical SEO checklist gives you 8 concrete points (load time, mobile-first, redirects, sitemap, robots.txt, clean HTML, structured data and internal links) that directly determine whether Google can crawl, index and rank your B2B site well. The short version: speed and mobile weigh the heaviest, and most mistakes hide in things that never appear on a design mockup. Start at the top and work your way down.

What is SEO worth to you? Calculate the pipeline from your organic traffic with the free SEO ROI calculator.

What is technical SEO and why is it a dev task?

Technical SEO is everything that lets search engines find, read and understand your site without problems. Content and backlinks are one side of SEO, but if your page loads slowly, is not mobile-friendly or ends up accidentally blocked in robots.txt, then even your best copy will not rank.

The problem on many B2B sites: marketing writes the content, but the decisions that cost rankings are taken in the codebase. A framework that loads too much JavaScript, a redirect chain nobody cleans up, a sitemap that is never refreshed. That is dev territory. At customerimpact.be we do not steer on vanity numbers like “number of indexed pages”, but on the question that counts: can search engines find the pages that bring you customers and revenue? If the answer is no, the work starts here.

If you want to know where you stand technically, a technical SEO audit or a broader SEO audit is the logical starting point. This checklist helps you understand the outcome of such an audit yourself and resolve it.

1. How important is load time really for your rankings?

Load time is one of the most underrated ranking factors, and its impact on visitor behavior is brutal. At a load time of 2 seconds the bounce rate, according to research by Pingdom, is around 6%, but at 5 seconds it jumps to 38%. A substantial share of your visitors drops off before the page has fully loaded. Google sees that behavior and draws its conclusions.

That difference is not subtle. Put the two load times side by side and you see how fast visitors fall away as the page gets slower:

What you can do concretely:

• Compress and serve images in modern formats (WebP, AVIF) with correct dimensions, no 4000px files in a 400px container.
• Remove or defer render-blocking JavaScript and CSS; only load what the first viewport needs.
• Set up caching and a CDN, and use lazy loading for images below the fold.
• Measure with Core Web Vitals (LCP, INP, CLS) instead of by feel.

Honest advice: do not chase a perfect 100/100 Lighthouse score if your site already loads fast. The last few points often cost days of work for a negligible result. Getting from 5 seconds to 2 wins you leads. Getting from 1.2 to 1.0 seconds wins nobody anything.

2. Why is mobile-first no longer an option?

Mobile-first is not a design preference, it is how Google evaluates your site according to the Google Search guidelines. Roughly half of website traffic (around 60%) comes from mobile devices, and Google uses mobile-first indexing: the mobile version of your page is the version that counts for rankings. What is not in your mobile HTML does not count for Google.

For developers that means:

• No content that only loads on desktop or is hidden behind a “read more” that does not render on mobile.
• Tap targets and buttons large enough, no horizontal scrolling, readable font sizes without zooming.
• The same structured data and metadata on mobile as on desktop.
• Test with real devices or throttled emulation, not just a narrow browser window.

For B2B with long sales cycles, mobile is easy to underestimate (“our decision-makers are on desktop anyway”). But the first orientation often happens on mobile, and if Google indexes you poorly there, you miss the entry point.

3. How do you prevent redirects and broken links from wasting your crawl?

Every redirect costs crawl time and load time, and redirect chains stack that cost. A chain of four redirects for one URL is wasted time that Google would rather spend on your real pages.

Keep it clean:

• Use 301 (permanent) for moved URLs, not 302 (temporary), unless it really is temporary.
• Flatten chains: have A point directly to the final destination, not via B and C.
• Clean up 404s by redirecting them to a relevant alternative or by fixing the internal links.
• Check after every migration or restructuring whether old URLs redirect correctly.

You can read more about this in the internal links piece.

4. What exactly should your sitemap and robots.txt do?

Your XML sitemap and robots.txt steer how search engines explore your site, and small mistakes here have big consequences. A wrongly placed rule in robots.txt can keep your whole site out of the index.

For the sitemap:

• Only include indexable, canonical URLs (no redirects, no noindex, no 404s).
• Keep it current: generate it dynamically so new pages enter it automatically.
• Submit it via Google Search Console and reference it in robots.txt.

For robots.txt:

• Do not block CSS or JS files that Google needs to render your page.
• Do not confuse Disallow (do not crawl) with noindex (do not index); they do different things.
• Test every change before you push it live, one wrong rule can turn out expensive.

5. Which HTML tags make your pages readable for Google?

Clean, semantic HTML is the foundation on which all technical SEO rests. Search engines read your structure through your tags, so a messy DOM makes the work harder for Google.

The essentials per page:

• One <h1> with your main topic, then a logical <h2>/<h3> hierarchy (do not choose headings based on font size).
• A unique, descriptive <title> and meta description per page, not one template for everything.
• Meaningful alt texts on images, both for accessibility and for image SEO.
• A canonical tag to prevent duplicate content when the same content is reachable via multiple URLs.
• Semantic elements (<nav>, <main>, <article>) instead of a sea of <div>s.

This overlaps strongly with on-page SEO, but the difference is who handles it: the tags themselves are dev work, the content inside them is content work. Agree on who does what, otherwise it stays undone.

6. What does structured data get you (and when not)?

Structured data (schema.org markup) explicitly tells search engines what your content means, and can produce rich results such as stars, FAQs or breadcrumbs in the search results. For B2B this is also increasingly relevant for GEO: AI search systems use structured data to understand and cite your content.

Where it pays off:

• Organization and LocalBusiness for your company details.
• FAQPage on pages with a real question-and-answer structure.
• BreadcrumbList for clear navigation paths.
• Article on your knowledge and blog pages.

Honest advice: do not put schema on pages where it does not fit, and do not invent FAQ markup for content that is not an FAQ. Google penalizes misleading structured data, and you cannot guarantee a rich result anyway. Implement it where it honestly describes the content (JSON-LD in the <head> is the recommended method), and validate with the Rich Results Test. You can read more about the AI side in the SEO for AI piece.

7. How do you keep your internal link structure crawlable?

Internal links are how Google understands the relationship between your pages and distributes authority. A page that is linked from nowhere (an “orphan page”) is almost invisible to Google.

Practically:

• Make sure every important page is linked from at least one other relevant page.
• Use descriptive anchor texts (“technical SEO checklist”) instead of “click here”.
• Use real <a href> links, not JavaScript onclicks that Google does not always follow.
• Keep click depth limited: important pages within three clicks from the homepage.

For B2B sites with many service pages, this is where a lot of value gets lost. Your services deserve organic inflow, so link to them deliberately. Read on in the internal links piece.

8. How do you make technical SEO a fixed part of your workflow?

Technical SEO is not a one-off project but maintenance, and the gain lies in building it into your dev process. One cleaned-up site that is then neglected for a year slowly decays again.

Build it in:

• Put Lighthouse or a comparable check in your CI pipeline, so a slow build stands out before it goes live.
• Monitor Google Search Console monthly for crawl errors, indexing problems and Core Web Vitals.
• Make a short pre-launch checklist (sitemap, robots.txt, redirects, structured data) mandatory at every release.
• Have marketing and dev look at the Search Console data together, not separately.

The common thread: steer on what brings in customers. Not every technical optimization is worth it, and a good team knows when something does not pay off. If you are in doubt about where your time pays off most, first look at the tools that measure your crawlability and speed, and prioritize by impact.

Frequently asked questions about technical SEO for developers

What is the difference between technical SEO and on-page SEO? Technical SEO is about how well search engines can crawl, render and index your site (speed, mobile-first, sitemap, redirects). On-page SEO is about the content of a page (headings, copy, keywords). The tags themselves are often dev work, the content content work.

Does technical SEO make sense for a small B2B site? Yes. It is precisely on smaller sites that one technical mistake (a slow homepage, a wrong robots.txt) costs you relatively much of your limited organic inflow. Setting up the basics well is usually a limited investment with lasting return.

How quickly do I see results from technical improvements? Speed and crawl improvements are often picked up within a few weeks once Google recrawls, but ranking improvements only follow after that. Count on weeks to months, depending on crawl frequency and competition.

Should I aim for a perfect Lighthouse score of 100? No. The biggest gain sits in the difference between slow and fast, not between fast and perfect. If you get the load time below the threshold where visitors drop off, optimizing further is often wasted time.

Which technical SEO mistake do you see most often? Pages that accidentally end up on noindex or blocked in robots.txt after a migration, plus redirect chains and non-redirected old URLs. A good pre-launch checklist catches most of these.

Would you rather we take over the technical work?

Have you gone through the checklist and see that there is work to be done, but the time or the SEO knowledge is missing in your dev team? Then we are happy to take a look with you. We are a small team that moves fast, advises honestly (including when something does not pay off) and steers on customers and revenue, not on vanity numbers. Check out our SEO service or let us review your technical foundation so your rankings and leads get the room they need.

Schedule your free intake