Technical SEO in 2026: A Complete Checklist and Site Audit, Step by Step

01 In short: what you need to know

• Technical SEO is the foundation. It won't lift weak content to the top, but without it even good content may not get indexed or may rank worse.
• The order is: first accessibility and indexing, then structure and duplicates, then content and markup, then speed and the mobile version.
• robots.txt controls crawling, not indexing. A page blocked in it can still appear in search. To remove it from the index you need noindex.
• One intent, one page. Two pages for the same query compete with each other.
• SEO and speed are one workstream, not two departments arguing.
• Check Search Console after every release. Most technical problems appear right after updates.

02 What technical SEO is and where to start an audit

Technical SEO is everything that helps search engines find, crawl, understand and index your pages, and helps users use them comfortably: speed, mobile version, security, clean structure.

The basic logic of search is simple, and an audit is built along it:

1. Crawling: can the bot reach the page?
2. Indexing: does the page get into the index, and is it the right version?
3. Understanding: is it clear what the page is about and how it relates to others?
4. Ranking and experience: is the page fast, convenient and secure?

If the first or second step breaks, optimizing the later ones doesn't matter. That's why the checklist below follows this order.

03 Indexing foundations

A clean robots.txt, an up-to-date sitemap.xml, correct status codes, canonical on duplicates and pagination, hreflang for multilingual versions. A Search Console check is a mandatory ritual after every release.

robots.txt

A file in the site root that tells bots which sections won't be crawled.

User-agent: *
Disallow: /admin/
Disallow: /cart/
Disallow: /checkout/
Disallow: /search/
Disallow: /*?sort=
Disallow: /*?utm_

Sitemap: https://example.com/sitemap.xml

Rules:

• robots.txt blocks crawling, not indexing. A page blocked in it but with external links may appear in results without a description.
• Don't combine Disallow and noindex on the same page. The bot won't crawl it and won't see the noindex.
• Don't block CSS, JS and images needed to render the page.
• Block service sections, the cart, internal search, sorting and tracking parameters.
• Check the file after changes: one stray Disallow: / line can "switch off" a site in search.

sitemap.xml

A list of important URLs for search engines.

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.com/poslugy/rozrobka-vebsajtiv</loc>
    <lastmod>2026-10-01</lastmod>
  </url>
</urlset>

Rules:

• Only canonical indexable URLs returning 200. No redirects, 404s, noindex or duplicates.
• Limit per file: 50,000 URLs or 50 MB uncompressed. For larger sites use a sitemap index.
• Set lastmod only when the content really changed. Constant "updating" erodes trust in the field.
• Add the sitemap in Search Console and reference it in robots.txt.
• For large sites, make separate sitemaps by type (services, blog, products).

Server response codes

Typical problems:

• Soft 404: a "not found" page returns 200. Set up a real 404.
• Redirect chains (A → B → C → D). Redirect directly to the final address.
• Redirecting all old URLs to the home page. Better to the closest page by meaning.
• Mixing up 302 instead of 301 during migrations.
• An unstable server: frequent 5xx errors reduce crawl frequency.

Indexing: noindex and Search Console

• Use noindex for pages that shouldn't appear in search: thank-you pages, internal search, service filters.

<meta name="robots" content="noindex, follow">

• In Search Console, regularly check the "Page indexing" report: why pages are "Crawled – currently not indexed", "Discovered – currently not indexed", "Duplicate without user-selected canonical".
• For individual important pages, use "URL Inspection".

04 Site structure, URLs and redirects

Clean URLs

• Short, readable, without extra parameters: /poslugy/seo-prosuvannya, not /index.php?id=137&cat=4.
• Lowercase, hyphens instead of underscores, no dates or extra nesting unless needed.
• Stable addresses: after publishing, don't change a URL without need, and if you do, use a 301.
• One format: with or without www, with or without a trailing slash. Redirect everything else to the main variant.

One protocol and one host

# Nginx: HTTP → HTTPS, www → non-www (example)
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}
server {
    listen 443 ssl;
    server_name www.example.com;
    return 301 https://example.com$request_uri;
}

# Apache (.htaccess)
RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteRule ^ https://example.com%{REQUEST_URI} [L,R=301]

Site architecture

• Click depth: important pages are reachable within 3 clicks of the home page.
• Logical sections: services, case studies, blog, about. Each has its own hub.
• Breadcrumbs with markup help both users and search engines.
• No orphan pages: every page has at least one internal link.

Migrations and redesigns

The most common cause of lost traffic. Before launch:

1. Collect a list of all old URLs (sitemap, analytics, Search Console, crawler).
2. Build a redirect map "old → new" with 1:1 closest-match pages.
3. Preserve title, H1, content and internal links wherever possible.
4. After launch, check redirects, update the sitemap, and watch Search Console daily for the first 2 weeks.

05 Duplicates, canonical and pagination

Duplicates dilute signals and make the search engine choose the "right" page instead of you.

Typical sources of duplicates:

• http/https, www/non-www, with and without trailing slash versions.
• Parameters: ?utm_, ?sort=, ?page=, ?sessionid=.
• Catalog filters and sorting.
• Print versions, AMP leftovers, test subdomains.
• Similar service pages with minimal differences.

Canonical

<link rel="canonical" href="https://example.com/poslugy/seo-prosuvannya">

Rules:

• Every indexable page has a self-referencing canonical to its own clean address.
• Duplicates with parameters point canonical to the main version.
• Canonical is a hint, not a directive, so back it with redirects and internal links.
• Don't point canonical to a page with noindex, a redirect or a 404.
• Don't mix canonical with hreflang: each language version has a canonical to itself.

Pagination

• Each pagination page has its own URL (?page=2 or /page/2/) and a self-referencing canonical.
• Don't point canonical of all pages to the first one if their content differs.
• Google no longer uses rel="prev/next", but logical "Next / Previous" links remain useful for users and crawling.
• For catalogs, make sure products on deeper pages are reachable through links, not only through a JS "Show more".

Filters and faceted navigation

• Decide which filter combinations have value as standalone landing pages (for example, "black entrance doors") and block the rest from indexing.
• For valuable combinations, create clean URLs with unique title/H1/text.
• Block the rest with noindex or via robots.txt (parameters), depending on the situation.

06 Multilingual sites and hreflang

For sites with Ukrainian and English (or other) versions:

<link rel="alternate" hreflang="uk" href="https://example.com/blog/article">
<link rel="alternate" hreflang="en" href="https://example.com/en/blog/article">
<link rel="alternate" hreflang="x-default" href="https://example.com/blog/article">

Rules:

• Reciprocity: if A links to B, B must link to A, and each page to itself.
• Correct language codes (uk, en, en-US) and regions.
• Each language version has a canonical to itself.
• Link only to existing indexable URLs that return 200.
• Don't automatically redirect users by browser language; provide a switcher. Otherwise the bot won't see all the versions.
• Translate language versions meaningfully, not just automatically.

07 Page content and semantics

One intent, one page. Title and H1 are aligned with the query but written for people.

Title, H1 and description

Nuances:

• Google may rewrite the title and snippet for a query. That's normal, don't panic, but quality source values raise the chance they're kept.
• Search engines don't use meta keywords.
• Don't duplicate titles and descriptions between pages. For templated pages (products, categories), generate them from a template with unique variables.

Content quality

• Content should answer the query more fully and usefully than competitors.
• Avoid thin pages (little text, no value) and duplication.
• Update outdated materials and keep the date of genuine updates.
• Show experience and expertise: author, case studies, sources, contacts (E-E-A-T principles).

08 Schema.org structured data

Markup helps a search engine understand the entities on a page. Use the JSON-LD format.

Organization (on the home page)

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "CROPE",
  "url": "https://crope.pro/",
  "logo": "https://crope.pro/assets/images/logo.png",
  "sameAs": [
    "https://www.linkedin.com/company/example",
    "https://www.facebook.com/example"
  ],
  "contactPoint": {
    "@type": "ContactPoint",
    "telephone": "+380974852292",
    "contactType": "customer service",
    "availableLanguage": ["uk", "en"]
  }
}
</script>

Article (for blog posts)

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Technical SEO in 2026: A Complete Checklist",
  "image": "https://crope.pro/assets/data/blog/article-05.jpg",
  "datePublished": "2026-07-14",
  "dateModified": "2026-10-15",
  "author": { "@type": "Person", "name": "Author Name" },
  "publisher": { "@type": "Organization", "name": "CROPE" },
  "mainEntityOfPage": "https://crope.pro/blog/tekhnichne-seo-dlya-saytiv-ahentstv-cheklist-2026"
}
</script>

BreadcrumbList

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://crope.pro/" },
    { "@type": "ListItem", "position": 2, "name": "Blog", "item": "https://crope.pro/blog" },
    { "@type": "ListItem", "position": 3, "name": "Technical SEO" }
  ]
}
</script>

Which types to use

About FAQ markup. Since 2023, Google shows rich results with questions and answers only for a limited set of authoritative sites (government and health). For most sites there will be no visual effect in search, but the markup remains valid and useful for understanding structure. Don't expect miracles, but it doesn't hurt if the questions genuinely exist on the page.

Markup rules:

• Mark up only what is visible to the user on the page.
• Don't invent ratings, reviews or prices.
• Validate in the Rich Results Test and the Schema.org validator.
• Watch for warnings in Search Console (the "Enhancements" section).

09 Internal linking

The link structure distributes "weight" and helps bots and people move around the site. For company sites, the right scheme is: blog → services → case studies → contacts.

Principles:

1. The blog leads to services. An article about site speed links to the "Website development" or "Technical support" service.
2. Services lead to case studies. Proof of results strengthens trust.
3. Case studies lead to contacts and relevant services.
4. Hubs and clusters. A main long-form article + details in separate pieces with mutual links. For example: the Core Web Vitals guide, landing pages, technical SEO and CMS selection.
5. Descriptive anchors: "technical SEO audit of a website", not "read more" or "here".
6. Links in body text, not only in the menu and footer.
7. Don't overdo it. Dozens of identical anchors on a page look unnatural.

How to check:

• Find orphan pages (no incoming internal links).
• Look at click depth for important pages.
• Check broken links (404) and links pointing to redirects.
• See which pages have the most internal links and whether they're the ones meant to bring traffic.

SEO and speed are one workstream, not two departments arguing. Metrics, linking and markup are checked together.

10 Speed, Core Web Vitals and the mobile version

Core Web Vitals

• Field data (CrUX) is evaluated at the 75th percentile, separately for mobile and desktop.
• Check URL groups in the "Core Web Vitals" report in Search Console.
• A detailed breakdown with code is in our Core Web Vitals article.

Mobile indexing

Google indexes sites by their mobile version (mobile-first indexing). This means:

• Content, links, structured data and metadata on the mobile version must match the desktop one.
• Don't hide important text and links on mobile.
• A configured viewport:

<meta name="viewport" content="width=device-width, initial-scale=1">

• Responsive layout is better than a separate mobile subdomain.
• Interactive elements are large enough, and text is readable without zooming.

Basic speed optimization

• Page and static caching, compression (Brotli/Gzip), HTTP/2 or HTTP/3.
• A CDN for static files.
• Minimal render-blocking CSS/JS, deferred third-party scripts.
• A current PHP version and an optimized database.

11 Images

• AVIF/WebP formats, responsive srcset and sizes.
• width and height specified (against CLS).
• loading="lazy" for images below the first screen, but not for the LCP element.
• Meaningful alt text: describe what's in the image, naturally and without keyword lists.
• Clear file names: modx-landing-example.webp, not IMG_2034.webp.
• Images are crawlable and not blocked in robots.txt.

<img src="/img/case-berezha-800.webp"
     srcset="/img/case-berezha-480.webp 480w, /img/case-berezha-800.webp 800w"
     sizes="(max-width: 600px) 100vw, 800px"
     width="800" height="500"
     loading="lazy"
     alt="Door online store: home page on mobile">

12 JavaScript and SEO

If a site is built on modern frameworks (Vue, React, Nuxt, Next), it's important that the search engine sees the content.

• Serve key content in HTML: SSR or SSG instead of rendering only in the browser.
• Make links real <a href="..."> elements, not click handlers.
• Don't hide important content behind events (clicks, scroll) that a bot doesn't perform.
• Metadata (title, description, canonical, hreflang) must be in the initial HTML or reliably rendered.
• Use "URL Inspection" in Search Console and look at the rendered HTML.
• JS errors and slow APIs must not block content from displaying.

13 Security and stability

• HTTPS across the whole site, a valid certificate, automatic renewal.
• No mixed content (HTTP resources on HTTPS pages).
• Protection against hacks and spam: CMS and plugin updates, backups, monitoring.
• A 404 page with useful navigation, not a redirect to the home page.
• Availability monitoring and server error tracking. Prolonged outages harm crawling.
• Checks for malicious code and third-party injections that can lead to penalties.

14 Technical SEO in the age of AI search

In 2026 users increasingly get answers in AI overviews and chat assistants. What this means technically:

• There is no special markup for AI overviews. The basis is the same: crawlable, indexed, high-quality, structured content.
• A clear structure (headings, lists, tables, short answers at the start of a section) helps both people and systems that extract answers.
• Make sure important pages aren't blocked for the bots you want. Decide on AI crawler access (for example, via robots.txt) deliberately, considering whether you want mentions and traffic from such systems.
• Prove expertise and authorship, give verifiable facts and sources.
• New "standards" like llms.txt don't yet have a proven effect on visibility, so treat them as an experiment, not a priority.
• For Bing and some other systems, IndexNow is useful for quickly notifying about page updates.

15 Audit tools

16 Audit order and priorities

Don't try to fix everything at once. Work by impact.

1. Critical (fix immediately)

• Blocked indexing (noindex, Disallow: /), 5xx errors.
• Wrong redirects, chains, loops, mass 404s on important pages.
• No HTTPS or mixed content.
• Content not displayed to the bot (JS problems).

2. High priority

• Duplicates and wrong canonical.
• Incorrect sitemap and robots.txt.
• Poor Core Web Vitals on key templates.
• A missing or broken mobile version.
• hreflang errors on multilingual sites.

3. Medium priority

• Unique title, H1 and description on key pages.
• Internal linking, orphan pages, broken links.
• Structured data.
• Image optimization.

4. Improvements

• Extending markup, fine-tuning filters and pagination.
• Crawl budget work (for large sites).
• Experiments with AI visibility.

How to run an audit

1. Data collection: access to Search Console, analytics, server logs, the CMS.
2. Site crawl and comparison with the sitemap and the index.
3. Indexing analysis: what's in the index, what isn't, and why.
4. Template checks (home page, category, service page, article, product).
5. Speed and mobile version from field data.
6. Content and linking of key pages.
7. A prioritized report: problem → impact → how to fix → owner → deadline.
8. A repeat audit 2–4 weeks after implementation.

17 Platform specifics: WordPress, MODX, Laravel, OpenCart

WordPress

• One SEO plugin (Yoast, Rank Math, SEOPress), without duplicated functions.
• Clean permalinks, configured canonical, sitemap, careful handling of categories and tags (their pages often create duplicates and thin content).
• Don't index author and date archives if they have no value.
• Control plugins and speed.

MODX

• Use resource fields: pagetitle, longtitle, description, introtext for title, H1 and descriptions through templates.
• Configure friendly URLs, canonical via a snippet or TV, and a sitemap via GoogleSiteMap or a custom snippet.
• For multilingual: contexts or third-party packages with correct hreflang.
• For catalogs on miniShop2/MiniShop3: control filters, pagination and parameters.
• Clean HTML and snippet caching give a speed advantage.

Laravel / custom projects

• Routes with human-readable slugs, redirects via middleware, correct response codes.
• Build meta tags, canonical, hreflang and JSON-LD in a single layout/component.
• Generate the sitemap with packages (for example, spatie/laravel-sitemap) or a custom command on a schedule.
• For Vue/Nuxt: SSR/SSG, page-level metadata, checking the rendered HTML.

OpenCart and online stores

• SEO URLs, unique title/H1/description for categories and products (from templates with variables).
• Managing filters, sorting, pagination and search parameters.
• Product, Offer and BreadcrumbList markup; checking availability and prices.
• Handling out-of-stock products (keep, redirect, 410), depending on the situation.
• Duplicates from different paths to a product in different categories: canonical to the main address.

18 The complete technical SEO checklist

Crawling and indexing

• robots.txt doesn't block anything important and references the sitemap
• sitemap.xml has only canonical indexable URLs (200)
• The sitemap is added in Search Console with no errors
• The "Page indexing" report is reviewed and exclusion reasons are understood
• noindex is set only where needed
• No mass 404s, 5xx errors or soft 404s

Structure and redirects

• One protocol (HTTPS) and one host (www/non-www)
• Clean, stable URLs
• 301 redirects with no chains or loops
• A 404 page with navigation exists
• Important pages within 3 clicks of the home page
• No orphan pages

Duplicates and canonical

• Self-referencing canonical on all indexable pages
• Parameters, filters and sorting handled (canonical/noindex/robots)
• Pagination has its own URLs and canonical
• Reciprocal hreflang with x-default (for multilingual)

Content and meta

• Unique title, H1 and description on every page
• One intent, one page; no cannibalization
• No thin or duplicate pages
• Alt texts are meaningful

Markup

• Organization, Article, BreadcrumbList (and Product / LocalBusiness as needed) in JSON-LD
• Markup matches visible content
• Rich Results Test shows no critical errors

Linking

• The "blog → services → case studies → contacts" scheme works
• Descriptive anchors, links in body text
• Broken links and links to redirects fixed

Speed and mobile

• Core Web Vitals in the green zone for key templates (field data)
• The mobile version has the same content and markup
• viewport configured, elements are touch-friendly
• Images optimized, width/height set

JS and security

• Key content and links are available in HTML
• HTTPS without mixed content
• Updates, backups, availability monitoring

Process

• Search Console check after every release
• A migration plan and redirect map before structural changes
• A repeat audit once a quarter or after major changes

19 FAQ

What is technical SEO in simple terms?

It's configuring a site so that search engines can easily find, understand and index its pages, and so that users find it fast and convenient: indexing, speed, mobile version, structure, markup, security.

Where should I start an SEO site audit?

With checking accessibility and indexing: robots.txt, sitemap.xml, response codes, the "Page indexing" report in Search Console. If pages don't get into the index, optimizing content and speed won't help.

How do robots.txt and noindex differ?

robots.txt controls crawling: it forbids bots from visiting pages. noindex controls indexing: it allows crawling but asks not to show the page in search. To remove a page from results you need noindex, not Disallow.

Do I need a sitemap.xml?

For small sites with good linking it's not critical, but it speeds up page discovery and helps control indexing. For large, new sites and sites with frequent changes, a sitemap is essential.

What is canonical and when is it needed?

It's a hint to the search engine about which version of a page is the main one. It's needed for duplicates (parameters, filters, different paths to the same page), and as a self-referencing one on all indexable pages.

How many characters should a title and description have?

Title roughly up to 55–60 characters, description 140–160. Actual truncation depends on pixel width, and Google may rewrite both elements. What matters is that they're unique, meaningful and match the query.

Is FAQ markup necessary?

Google shows FAQ rich results only for a limited set of sites, so don't expect a big visual effect. The markup is acceptable if the questions and answers genuinely exist on the page.

How often should I run a technical audit?

A full audit once a quarter or half a year, plus a quick Search Console check after every release and migration. Large, dynamic sites need constant monitoring.

Does speed affect SEO?

Yes, Core Web Vitals are one of the page experience signals, and speed also directly affects conversion. Details in our Core Web Vitals guide.

How long until I see results?

Fixing indexing blockers can show an effect within days or weeks. Improvements to structure, speed and linking usually show up within 1–3 months, depending on crawl frequency and competition.

Should I block AI crawlers in robots.txt?

It's a business decision. Open access gives a chance of mentions and traffic from AI systems; blocking limits use of your content. Decide deliberately and revisit as conditions change.

20 Summary

Technical SEO in 2026 is not a set of "magic" settings but a discipline: making sure the site is accessible, understandable to search engines, fast and stable after every release.

The order of action:

1. Indexing: robots.txt, sitemap, response codes, the Search Console report.
2. Structure: clean URLs, one host and protocol, correct redirects.
3. Duplicates: canonical, filters, pagination, hreflang.
4. Content and markup: unique title/H1/description, Schema.org.
5. Linking: blog → services → case studies → contacts.
6. Speed and mobile version: Core Web Vitals from field data.
7. Process: a check after every release and regular audits.

Need a technical SEO audit of your website?

We'll check indexing, structure, markup, speed and linking, build a fix plan ordered by impact on traffic and help implement it.

Order an audit at crope.pro