The Technical SEO Checklist: What Development Should Get Right, and How to Check It at Acceptance
“The site is finished — we will worry about SEO later.” Every time that sentence is said, another layer is added to the eventual repair bill.
Technical SEO is not a value-added service from the marketing department. It is baseline quality in website development, in the way that waterproofing is baseline quality in a building fit-out. It handles one thing: whether a search engine can read your pages and understand what they are about. This guide sets out the items that belong in the development phase, and how somebody without an engineering background can check them at acceptance.
Crawlable and indexable: the precondition for everything
A search engine has to be able to read the page before anything else you do matters. A few things to confirm at this layer:
The content has to be present in the page source. Some sites generate their content entirely by executing code in the browser, and search engines cannot always retrieve it in full. That belongs in the decision when the technical architecture is chosen, rather than surfacing after launch when only the homepage has been indexed.
Do not block yourself by accident. The crawl rules file in the site root (robots.txt) and the indexing directive on the page (noindex) exist to control which pages get indexed, and they are also where accidents most often happen: the staging environment was set to “do not index,” nobody removed it at launch, and the entire site disappears from search results. Put this on the item-by-item pre-launch confirmation; pair it with the Pre-Launch Website Checklist.
The staging environment must not be indexable. If development URLs get crawled, they compete with the production site. Staging should sit behind a password, not rely on a directive alone.
URL structure: hard to change once it is set
URLs carry the highest regret cost of anything on this list, because changing them means dealing with redirects and re-indexing. A few principles to hold to at design time:
- Meaningful and shallow: the URL alone should indicate what the page covers and where it sits
- Stable: keep volatile information out of the URL (dates, sequence numbers, campaign names)
- Consistent: one choice across the site for hyphens or underscores, casing, and whether a trailing slash is used
- One piece of content, one URL: the same article should not be reachable by several different paths
The last point matters most. When the same content can be reached through multiple URLs — with and without www, with and without a trailing slash, with tracking parameters attached — use a canonical URL to nominate the official version, so that search engines do not count one piece of content several times over.
Changing URLs on a site that is already live is redesign-scale work; for the method, see the Website Redesign SEO Checklist and How a Website Redesign Actually Runs.
Titles and descriptions: editable by you, and never duplicated
Every page needs its own title and meta description. They are the first thing a user sees in the search results.
What development needs to confirm is the mechanism that generates them, not just the homepage:
- Every page type (homepage, service page, article, listing, category) needs a sensible default rule
- The admin system has to allow per-page overrides so that the marketing team can adjust them
- Page two onwards of a listing must not be identical to page one
- Avoid template sentences where only one word changes across the whole site
The same principle applies to the preview information shown when a page is shared on social platforms — title, description, thumbnail. This is routinely missed, and the result is a blank card when somebody posts the link.
How to write titles that match what people are actually searching for is a content-side job; see How to Run a Brand Blog.
Structured data: making the page legible to machines
Structured data is a block of supplementary information written into the page for machines to read, marking up what the page is — an article, a product, a set of frequently asked questions, a local business. It does not guarantee better rankings, but it helps search engines classify the page correctly, and it is a prerequisite for certain search result formats.
Two principles apply in practice:
Only mark up content that is genuinely visible on the page. Markup that disagrees with the visible content is the main reason for an abuse determination.
Follow the official documentation for formats and supported types. This area changes frequently, so avoid copying older examples from around the web and validate with the search engine’s own testing tool instead.
Structured data for customer reviews is particularly sensitive; whether you can use it and how to do so defensibly is covered separately in On-Site Customer Reviews and Review Schema.
Sitemaps and indexing status
A sitemap is a list of the URLs you want indexed. It should be generated automatically by the system and updated as content changes, rather than maintained by hand as a file that quietly goes stale. At acceptance you can simply open it and look: are the pages listed the ones you expect to be indexed? Have any test pages, duplicates, or deleted URLs crept in?
After launch, register the site with the free management tools the search engines provide, and review indexing status and error reports regularly. This should be set up as part of delivery, with account access handed over — the account belongs to you, not to the vendor, and that is worth writing into the contract. For the related contract items, see How to Choose a Software Development Company.
Speed and mobile
Load speed and mobile experience affect users and search performance at the same time. What development can do includes compressing images and controlling their dimensions, loading only the code and fonts actually needed, preventing layout from shifting as the page loads, and making proper use of caching.
How to read the metrics, how to prioritize improvements, and how to write acceptance conditions into the contract are covered in full in the Website Speed Optimization guide and not repeated here.
Mobile should be accepted on a real device, not by shrinking a desktop browser window. What matters is font size, tap target size, the form input experience, and whether any content requires horizontal scrolling to read.
Images and accessibility
Alternative text on images exists so that users who cannot see the image still understand the content, and it helps search engines interpret the image as a by-product. The principle is to describe what the image shows rather than to pack in keywords. Purely decorative images should be left empty so that they do not add noise.
Related items include a meaningful heading hierarchy, form fields paired with proper labels, and link text that indicates its destination (rather than a page full of “click here”). These sit within accessibility as well; for the full approach, see A Web Accessibility Guide for Businesses.
Multilingual sites additionally need language markup and a mapping between language versions; that part is covered in the Multilingual Website Development Guide.
Practical checks at acceptance
Several of these need no engineering background at all:
| Check | How to do it | What to look for |
|---|---|---|
| Titles | Read the browser tab on each page | Distinct from one another, and comprehensible |
| Mobile | Run the main flows on an actual phone | Font size, buttons, forms, scrolling |
| Links | Click through the main internal links | Anything broken or pointing to the wrong place |
| Sitemap | Ask the vendor for the URL and open it | Whether the pages listed are the ones to index |
| Indexing settings | Ask the vendor to explain how blocking is lifted at launch | Any leftover settings from the staging period |
| Share preview | Paste the URL into a messaging app | Title, description, and thumbnail appear correctly |
Writing these into the acceptance criteria is far less work than repairing them afterwards. For how to design the acceptance process and grade defects, see How Software Acceptance Works.
Most technical SEO items are not difficult. What is difficult is having somebody responsible for them during development. They are largely not paid extras but the baseline quality a website should have; left until after launch, they cost several times as much, and a few of them cannot be recovered at all.
If you are planning a new site or preparing a redesign and want to confirm that these fundamentals are inside the scope, talk to NETVANA about your website requirements. For what the web development service includes and delivers, see the software services overview; NETVANA quotes software services individually rather than selling fixed packages.
Further reading: for accepting speed metrics, see the Website Speed Optimization guide; for the content side, see How to Run a Brand Blog; for URL migration during a redesign, see the Website Redesign SEO Checklist; for where accessibility and readability overlap, see A Web Accessibility Guide for Businesses; and for reading the data afterwards, see A Practical Guide to GA4.
