Technical SEO for a new website: what should be included?
Technical SEO for a new website should cover indexation controls, a logical URL structure, useful metadata and headings, canonicals, a sitemap, robots rules, redirects from old URLs, mobile performance, appropriate structured data, Search Console and analytics. Installing an SEO plugin does not prove that any of these elements have been configured correctly.
Agree the scope before signing the contract. An unmanaged migration may disconnect working URLs, links and search traffic the business has already earned.
Technical SEO is not a ranking promise
Technical SEO helps a search engine find, read and interpret a website. It cannot replace a clear offer, useful content or ongoing visibility work.
According to the Google Search technical requirements, checked on 12 September 2026, a page needs to meet only three minimum conditions to be eligible for indexing:
- Googlebot is not blocked,
- the URL returns an HTTP
200success status, - the page contains indexable content.
Meeting the minimum does not guarantee indexing or a strong position. A good implementation removes technical barriers and supports future work. It does not sell a search ranking that a supplier cannot control.
1. Crawler access and indexation controls
Before launch, crawl the website as a search engine would. Important pages must be public, return the correct response and avoid accidental noindex directives.
The review should include:
- service, product, category, article and contact pages,
- invalid URLs and the behaviour of the 404 page,
- redirect chains and loops,
- resources required to display the primary content,
- mobile content and material generated with JavaScript,
- restrictions carried over from the staging environment.
Staging sites often use noindex before approval, so the production build must remove it deliberately. Google also explains that robots.txt mainly manages crawler traffic and is not a reliable way to keep a page out of search. Its guide to robots.txt and indexing controls explains the distinction.
2. Site structure, URLs and internal links
The information architecture should follow the offer and customer search behaviour. Important pages should not require an internal search or several unpredictable clicks.
Before development starts, define:
- the main service or product groups,
- relationships between overview and detail pages,
- short, descriptive URLs,
- navigation and contextual links to priority content,
- rules for filters, parameters and variants,
- connections between language versions.
Keep useful URLs stable. A technology change alone does not justify replacing every path. The Next.js and WordPress comparison explains the platform decision, but either can support a clear structure.
3. Titles, descriptions and heading hierarchy
Every important page needs a specific title and description. Copying the company name or generating strings of keywords is not a substitute.
The implementation should include:
- one clear topic for the main page heading,
- logical headings for subsequent sections,
- a unique document title,
- a description written for the right searcher,
- alternative text for informative images,
- meaningful names for links and buttons.
Google may rewrite a displayed title or snippet, but good metadata still defines the intended topic and supports future optimisation.
4. Canonicals, sitemaps and duplicate URL rules
A website may expose similar content through parameters or product variants. A canonical identifies the preferred version and should agree with links, redirects and the sitemap.
Google recommends selecting a canonical and including preferred URLs in the sitemap. A canonical is a signal, not a command.
The acceptance review should confirm that:
- each canonical points to the correct page version,
- language variants do not accidentally nominate one language as canonical for all users,
- the sitemap contains only public URLs intended for indexing,
- URLs in the sitemap return a
200response, robots.txtreferences the current sitemap,- staging pages, internal search results and unnecessary parameters stay out of it.
Submitting a sitemap does not guarantee crawling or indexing. Google's guide calls it a hint and explains the Sitemaps report.
5. Structured data only where it fits
Structured data identifies the type of information on a page. Suitable types may include organisation, article, product, breadcrumb or local business data.
Adding every available type is not useful. The markup must represent visible content, and it must not contain invented ratings, prices or questions added merely to pursue a richer result.
Validate it with the Rich Results Test, but do not treat a pass as a display guarantee. Google states this in its structured data guidelines.
6. Performance and mobile use
Technical SEO should reflect real use, not one green test. Images, fonts, scripts and third-party components can change performance after publication.
The current thresholds for a good Core Web Vitals experience are:
- LCP within 2.5 seconds,
- INP of 200 milliseconds or less,
- CLS of 0.1 or less.
Google recommends assessing the 75th percentile of visits, separately for mobile and desktop. These values come from the Web Vitals documentation, checked on 12 September 2026.
Use laboratory tests before launch and review field data later. Performance varies with the device, connection and user behaviour.
7. Redirects when replacing an existing website
When replacing a live website, collect its URLs first. Keep each valuable address or redirect it to the closest equivalent. Sending everything to the homepage loses the meaning of old pages.
A migration plan should include:
- a map of old and new URLs,
- permanent redirects without unnecessary chains,
- updated internal links,
- checks for images and documents receiving search visits,
- a full crawl after publication,
- monitoring of errors and indexation in Search Console.
The guide to a website redesign without avoidable SEO losses covers this stage in more detail.
8. Search Console, analytics and an acceptance report
After launch, the owner should have administrative access to measurement tools under an account they control.
The launch minimum includes:
- a verified Google Search Console property,
- a submitted sitemap,
- URL inspection for several priority pages,
- measurement of important user actions,
- a record of implemented redirects,
- a report of errors found during the final crawl.
Analytics should respect applicable consent requirements. Test forms, calls or purchases end to end, because code in the source does not prove correct measurement.
What is not automatically included in technical SEO?
The technical foundation does not create continuous search growth by itself. A separate scope may be needed for:
- research into customer questions and search demand,
- writing service page content,
- regular publishing and content updates,
- local visibility and business profile work,
- earning genuine mentions and links,
- competitor analysis,
- conversion rate optimisation.
Content should not be added as an afterthought to an arbitrary design. The guide to preparing content for a new website lists the information worth collecting before work begins.
12 questions to ask before signing the contract
Request specific answers:
- Who will define the URL structure and internal links?
- Will every important page receive its own title, description and canonical?
- How will filters, parameters and language versions be handled?
- Will the sitemap be generated and updated automatically?
- Who removes staging indexation blocks at launch?
- How will response codes, 404 pages and redirects be tested?
- Does the project include a full website crawl before acceptance?
- Which structured data types genuinely fit this website?
- How will mobile performance be tested?
- Does a migration include a map of old and new URLs?
- Who owns the Search Console and analytics properties?
- Which report will confirm that the work was completed?
A useful answer describes the test and expected result, not only the name of a plugin. Technical SEO is part of a new build in the AMCompany service scope, rather than an item added after publication. You can also review selected website projects. If you have received a proposal or plan to replace an existing website, send the project scope. Missing foundations are easier to identify before development than to rebuild after launch.
Let’s discuss a website with a clear job to do
Tell me what you need and where you are in the process. I will reply with questions and a practical next step.