An SEO-friendly website is a site that Google can crawl, render and interpret without friction, and that a person can use from their phone. Almost everything that makes it so is decided before a single line of content exists: where the domain lives, how deep the architecture goes, how much of the text depends on JavaScript. They are also the decisions that cost the most to change later.
Most guides on this topic list good practice without putting numbers on it. Here the numbers are included, and they come from the Web Almanac 2025, from a Vercel and MERJ study on how Googlebot handles JavaScript, from Google's documentation and from the Search Console data of a project we manage.
The decisions you cannot undo later
This table is the quickest way I have found to explain to a client why SEO should be brought in at the wireframe stage and not at launch.
| Decision | When it is made | What it costs to fix later |
|---|---|---|
| Single domain or sections on a subdomain | Before buying hosting | Migration, redirect chains, authority rebuilt from scratch |
| Depth of the architecture | Wireframe | Rebuilding menus, breadcrumbs and internal links |
| URL format | First content upload | A 301 redirect for every page, to be maintained for years |
| CMS and theme | Technology choice | Rebuilding the front end |
| Share of content that depends on JavaScript | Framework choice | Introducing server-side rendering on a project already in production |
| Language handling | Before the second language | Hreflang, duplicate content, the wrong page in the SERPs for months |
The last two rows are the ones that barely come up on page one for this query, and that is where most visibility is lost today. On Google UK, the AI Overview at the top of the results for "seo friendly website" sums up the ranking guides as mobile design, page speed, HTTPS, clean architecture, headings, alt text and internal links: JavaScript rendering and language handling are not on the list (DataForSEO, Google UK, September 2026).
Single domain or subdomain: first-hand data
Google does not penalise a subdomain as such. The point is a different one: a subdomain is a second site that has to be grown, and almost nobody actually grows it.
An Italian outdoor equipment e-commerce business we work with has its shop on a subdomain separate from the main site, a choice made years ago when the site was built. These are the organic figures for the two hosts over the same period.
| Host | Organic clicks | Impressions | Average mobile position |
|---|---|---|---|
| Main domain (www) | 4,484 | 190,200 | 5.2 |
| Shop subdomain | 82 | 4,718 | 13.3 |
The subdomain collects 1.8% of the main domain's clicks and ranks on average eight positions lower. It is not a controlled experiment: the two hosts have different content and different link histories. That is precisely the point. Splitting the site across two hosts means doing the authority work twice, and in practice it ends up being done on only one.
The rule I apply: a subfolder for everything that needs to rank, so blog, shop and category pages; a subdomain only for things that have nothing to do with search, such as a login area or an internal tool. The choice of domain and its structure comes before everything else.
Architecture: how many pages, and how far from the homepage
An SEO-friendly architecture comes from keyword research, not from the company org chart. Each page answers one question, and different questions need different pages even when the sales team considers them the same product.
Macropix, a Milan-based LED screen manufacturer and long-standing Visilay client, has one page for LED walls, one for the indoor version, one for the outdoor version and one for totems. Four pages for what is internally a single product family: the split comes from search intent, not from the catalogue.
Two practical constraints to respect at wireframe stage. No page you want to rank should sit more than three clicks from the homepage, and breadcrumbs are the cheapest way to shorten that distance on every deep page. And every new page must receive at least one internal link from a page Googlebot already visits: a page that exists only in the sitemap is a page Google finds late.
URLs are written once
Short, lowercase, words separated by hyphens, no dates and no version numbers, no parameters for content that needs to rank. The most useful rule is also the most boring: you do not change a URL without a serious reason, because every change is a redirect to maintain for as long as the site exists.
The canonical is the second half of the job and is missing more often than you would think: according to the SEO chapter of the Web Almanac 2025, the canonical tag is present on 68% of the desktop pages analysed. The remaining third leave it to Google to decide which version of the URL counts, and Google only sometimes decides well.
The CMS matters more than the theme you put on it
The CMS chapter of the Web Almanac 2025 cross-references field data from the Chrome UX Report with the platform in use. 45% of WordPress sites pass Core Web Vitals; on Duda the share reaches 85%. The sample is global and an average describes no site in particular, but it says something true: the platform moves the starting point.
WordPress is not slow in itself. It is that the WordPress average is made up of heavy themes and plugins piled up over the years. If that is your choice, and for most company websites it is a reasonable one, the real decision is the theme and the number of plugins, not the CMS.
How much JavaScript the site can carry
Google renders JavaScript, and the data confirms it: in the Vercel and MERJ study of more than 100,000 Googlebot requests to nextjs.org, 100% of indexable HTML pages were fully rendered, including those with complex JavaScript interactions.
The problem is time. In the same study the rendering queue latency had a median of 10 seconds, a 75th percentile of 26 seconds, a 90th percentile of around 3 hours and a 99th percentile of around 18 hours. Google's documentation puts it more cautiously: "The page may stay on this queue for a few seconds, but it can take longer than that".
The part that most guides leave out concerns the other crawlers. According to Vercel's analysis of its own logs, none of the main AI crawlers executes JavaScript: OpenAI's GPTBot, Anthropic's ClaudeBot and PerplexityBot download JS files without running them. In the month analysed, December 2024 on the Vercel network and therefore on mostly US traffic, GPTBot made 569 million requests, ClaudeBot 370 million and PerplexityBot 24.4 million: together around 28% of Googlebot's volume. The crawlers are the same in every market, and their behaviour does not change from one country to the next.
Translated into a project decision: the text you want read must already be in the HTML the server returns. If the site uses React, Vue or a similar framework, server-side rendering is not an optimisation, it is a requirement. The check takes thirty seconds: open the page with JavaScript disabled in the browser and see what is left. On the generative model side it is also worth reading what happens to AI-generated content and what an llms.txt file is actually for.
The real performance thresholds
There are three Core Web Vitals and the thresholds have not changed in years. They are measured at the 75th percentile of real visits, not in a lab test.
| Metric | What it measures | "Good" threshold at the 75th percentile |
|---|---|---|
| LCP | When the main element of the page appears | 2.5 seconds or less |
| INP | How responsive the site is to interactions | 200 milliseconds or less |
| CLS | Layout stability during loading | 0.1 or less |
The gap between theory and the real web is wide. In July 2025, 48% of sites passed Core Web Vitals on mobile and 56% on desktop, up from 44% and 55% in 2024. A lesser-known figure from the same chapter: inner pages pass more often than homepages, by 11 points on mobile and 14 on desktop. If a site has a performance problem, very often it has it on the homepage, which is also the page people look at first and fix last. For how to tackle it, see the page speed guide.
The phone is the version that counts
Since October 2023 Google has indexed the whole web with Googlebot Smartphone. Whatever is missing from the mobile version does not exist for Google. On the outdoor e-commerce site mentioned above, over the same period, 69% of organic clicks and 65% of impressions came from mobile.
The two mistakes I see most often both originate at the design stage: content present on desktop and removed at the mobile breakpoint, and images served at the same resolution on every device. The second is solved with srcset and modern formats, and image optimisation is the first place to look when LCP is out of range.
What to check before going live
These are one-off checks, and they are the same ones I later find missing in audits. The right-hand column shows how widespread they are across the web, according to the Web Almanac 2025.
| Element | Share of pages or sites that have it (desktop, 2025) |
|---|---|
| robots.txt returning 200 | 84.9% (returns 404 in 13.3% of cases) |
| HTTPS | 91.7% |
| Meta description | 67.7% |
| Canonical tag | 68% |
| H1 present | 71% |
| Images with an alt attribute | 60% (median value) |
| llms.txt file | 2.13% |
To these I add the XML sitemap submitted in Search Console, structured data on the page types that support it, and hand-written titles and meta descriptions on the pages that matter. If the site is multilingual from day one, hreflang is set up before the second language is published, not after: international SEO is the item that generates the most recovery work.
If the site is already live
Rebuilding everything rarely pays off. The order I work in, from the best effect-to-cost ratio to the worst:
- Check that the text is in the server HTML. If it is not, everything else is pointless.
- Fix canonicals, robots and indexing: hours of work, not weeks.
- Work on internal links and on the depth of the pages that already bring impressions.
- Work on LCP and images, starting from the pages with the most impressions in Search Console.
- Touch URLs only if there is a structural problem, never for looks, and always with one-to-one 301 redirects.
The rest is ordinary technical SEO and on-page optimisation, which can be done on a live site without taking it back to the drawing board.
How long a new site takes to bring in traffic
Wrong expectations on this point ruin more projects than any technical error. A 2025 Ahrefs study of one million URLs finds that 1.74% of published pages reach the top 10 within a year, that the page in first position is on average 5 years old and that 72.9% of top 10 pages are more than three years old. An earlier study, from 2023, on an index of 14 billion pages, found that 96.55% get no traffic from Google at all.
Both samples are mostly English-language and US-market, which makes them a fair guide for the UK. In smaller language markets competition on many queries is lower and timescales can shorten, but the order of magnitude stays the same: months, not weeks. For context, in Italy, where most of our clients are based, Istat reports that in 2025 76.5% of companies with at least 10 employees had a website, so competition exists even in industrial niches.
For Macropix, the Italian keyword for "advertising monitor" ("monitor pubblicitario") went from position 88 to position 2, and across the tracked cluster the domain holds a 25.55% share of voice, ahead of amazon.it. First position for "ledwall" came after several years of work on the whole site structure, not after a single intervention. The full case is in the article on SEO for manufacturing, and the other projects are collected on the projects page.
If the site is still on paper, this is the phase in which SEO work costs less than at any other point, and it is also the one in which it is requested least often: SEO consultancy at the design stage is worth more than six months of recovery after launch.
The rule I would impose on a new project
If I could impose a single check on anyone building a site, it would be this: open any page with JavaScript disabled and find the text, the links and the headings in it. Almost everything else follows from that, because a site that passes that test also copes with Google's rendering queue, with the crawlers that do not execute JavaScript and with a phone on a patchy 4G signal. In 2020 that test served a single audience. Today there are at least four, and three of them have no rendering engine.
Frequently asked questions
No. The theme affects performance and heading structure, but it does not decide domain, architecture, URLs, rendering and language handling, which are the most expensive items to fix. The Web Almanac 2025 finds that 45% of WordPress sites pass Core Web Vitals: the difference between those and the rest almost always lies in the number of plugins and the weight of the theme, not in the SEO-friendly label on the theme itself.
A subfolder, if they need to rank. Google does not penalise subdomains, but a subdomain has to be grown as a site in its own right. On an Italian e-commerce site we manage, the shop subdomain collects 1.8% of the main domain's organic clicks and ranks on average eight positions lower. A subdomain remains the right choice for login areas and internal tools.
The official Core Web Vitals thresholds, measured at the 75th percentile of real visits, are: LCP within 2.5 seconds, INP within 200 milliseconds, CLS at or below 0.1. In July 2025, 48% of sites met them on mobile and 56% on desktop. The value that counts is the Chrome UX Report field data, not the score from a lab test.
Not in themselves. In the Vercel and MERJ study of more than 100,000 Googlebot requests, 100% of indexable HTML pages were rendered, but the rendering queue had a median of 10 seconds and a 90th percentile of around 3 hours. On top of that, GPTBot, ClaudeBot and PerplexityBot do not execute JavaScript. With server-side rendering the problem does not arise; without it, the content risks being invisible to answer engines.
Almost never. In order: check that the text is in the HTML returned by the server, fix canonicals and indexing, then internal links and page depth, then LCP and images starting from the pages with the most impressions. URLs are only touched for a structural problem, with one-to-one 301 redirects. A full rebuild is justified when rendering is entirely client-side and the platform does not allow you to change it.
According to the 2025 Ahrefs study of one million URLs, 1.74% of published pages reach the top 10 within a year and the page in first position is on average 5 years old. The sample is mostly English-language: in less crowded niches timescales shorten, but the unit of measurement is still months. For one industrial client, first position on the main keyword came after years of work on the whole site structure.
