SEO-friendly website: a 25-point technical checklist
What makes an SEO-friendly website: a 25-point technical requirements list to hand your developer before a new site is built; crawling, speed, multilingual.
By Roozbeh Nazari · CEO
The phrase "SEO-friendly website" appears in most proposals, but what it covers is rarely defined. This article makes that definition: a 25-point technical requirements list that can be handed to the developer when a new site is being built or an existing one redesigned. The 20-item production checklist we prepared for auditing a live site looks after the fact; the list here gathers the items that belong in the brief while the site is being built, before code is written or a theme is chosen. In Google's own words, meeting the technical requirements does not guarantee that a page is indexed, it only makes it eligible; an SEO-friendly website is one that secures that eligibility at the design stage. The items are grouped in five sections, and each is written so a developer can answer "done" or "not done".
Crawling and indexing: 1-6
One, every page is served at a publicly accessible address with a 200 status code; content that requires login, depends on parameters or exists only client-side is content the crawler cannot see. Two, robots.txt in production does not block Googlebot, and the "disallow all" line is removed when the development environment goes live; that single line is the most expensive launch mistake we have seen. Three, every page has one canonical address and internal links point to it; www and non-www, trailing slash and letter case all redirect to a single version. Four, the XML sitemap contains only canonical pages that should be indexed and return 200, and it updates automatically. Five, redirects are single-step; there are no chains or loops, and the mapping table from old addresses to new ones is ready before launch. Six, the 404 page really returns 404; soft 404 pages that say "not found" and return 200 waste index budget.
Site architecture and page structure: 7-12
Seven, every important page is reachable within three clicks of the home page, and internal links are real anchor tags; fake links driven by JavaScript events are not links to the crawler. Eight, the URL structure is readable and hierarchical; the category and subpage relationship shows in the address. Nine, every page has one H1 and a meaningful heading hierarchy; text that is large for design reasons is enlarged with styles, not heading tags. Ten, the title tag and meta description are editable per page from the CMS, and the template default is not the same on every page. Eleven, pagination, filter and sort parameters are either canonicalised to the main page or marked not to be indexed; on e-commerce sites this item alone can generate hundreds of thousands of unnecessary addresses. Twelve, structured data is generated from templates by page type: Organization for the corporate page, Article for articles, the relevant type for a clinic or local business; it passes the testing tool without errors and does not contradict the content.
Speed and Core Web Vitals: 13-17
Thirteen, the site's target is field data, not a lab score: the thresholds of LCP 2.5 seconds, INP 200 milliseconds and CLS 0.1 are met at the 75th percentile of visits on mobile and desktop. We explained why these thresholds look different across measurement tools in site speed test. Fourteen, images are served in modern formats, with dimensions specified and off-screen images lazy-loaded; the main above-the-fold image is not lazy-loaded. Fifteen, fonts are self-hosted and a system font is shown until they load; this is both a speed and a CLS item. Sixteen, third-party scripts are kept in an inventory, each has an owner, and they are published through the tag manager; the number of marketing scripts grows over time and they are the item that damages INP most. Seventeen, the page responds fast on first request: server-side rendering or static generation is preferred, cache headers are defined and a content delivery network is used. We discussed which metric really matters in Core Web Vitals 2026.
Multilingual and international structure: 18-21
Eighteen, every language version lives at its own address; it is not served as content that changes at the same address according to language, cookie or browser setting. Nineteen, hreflang tags list every language version including the page itself, and they are reciprocal; Google's documentation asks for this explicitly and one-way tags are ignored. Twenty, language redirection is not automatic; sites that redirect server-side by browser language leave Googlebot seeing only one version, a mistake we experienced and documented on our own site. Twenty-one, right-to-left languages are tested with a mirrored design; on the Arabic and Persian versions, address, structured data and font decisions are reviewed separately. We collected the most frequent errors in auditing these four items in hreflang errors.
Pre-launch and measurement: 22-25
Twenty-two, Search Console and the analytics property are set up before launch; first-day data is not lost and crawl stats are watched on launch day. Twenty-three, the whole site is crawled with a crawler before launch; it does not go live until the list of broken links, missing titles, duplicate content and wrong canonicals is at zero. Twenty-four, development and preview environments are not indexed; they are closed with password protection or a noindex header, and it is separately verified that this closure was not carried into production at launch. Twenty-five, every item on the list has an owner and an acceptance criterion; if "SEO-friendly" is written in the contract, which of these 25 items are in the delivery scope is written too.
SEO-friendly site: whose hands the list stays in
The answer to how an SEO-friendly website is built is how many of the 25 items above are "done" on launch day; in our practice that number is below ten on projects where the list never entered the brief and above twenty where it did, and the difference comes back as remediation cost in the first months after launch. An SEO-friendly site comes not from the designer's or developer's good intentions but from items written into the brief and checked at delivery. Hand the list to the developer at the start of the project, write who owns each item, and tick the items one by one a week before launch. If you use a theme or a ready-made platform, ask before buying how many of the items the platform covers; "SEO-friendly theme" usually means only that the title tag can be edited. We apply this list as part of the brief in our technical SEO service when a new site is built or an existing one is migrated; after launch, the production audit of the same site takes over. Google's own starter guide says the same thing: search engine optimisation is the step taken after the technical requirements are met, and if the requirements are not met at the design stage, every later step costs more.