WEB WEB-04

Technical SEO and User Experience: Turning Your Website into a Business Asset

Technical SEO and user experience decide whether your site can be found and used. This guide covers crawling, indexing, canonicals, structured data, Core Web Vitals and accessibility with current thresholds, what evidence exists on their effect on conversion, and how to prioritize.

By Maccam Network Editorial Team
Published
Read 15 min
Hub SEO & Visibility
Table of contents

Technical SEO and user experience are often treated as separate projects with separate teams and budgets. That is an organizational error, not a conceptual one. They answer the same question: can the right person find your site and do what they need to do on it? Technical SEO ensures search engines can crawl, understand and index your pages. User experience ensures that once someone arrives, the page loads, responds, stays out of the way and is usable by everyone.

Our thesis: a website is a business asset when it meets both conditions at once, and it is measured by what it produces for the business, not by a score. A fast site Google cannot index does not sell. A perfectly indexed site that freezes on mobile, or that a person with a disability cannot use, does not either.

Two caveats up front, because the market sells this topic with more certainty than exists. First, Google says Core Web Vitals are used by its ranking systems, but that good scores do not guarantee ranking at the top. Second, the public evidence on how speed affects conversion comes from individual company cases: it helps orient you, not predict your result. This article works with what is documented and marks where that ends.

The design of a site’s content structure (topic hierarchy, internal linking, clusters) is covered in content architecture for visibility and we do not repeat it here. This article deals with the technical and usability foundation that architecture runs on.

Three questions, three layers

Three layers: access, understanding and use
Question Layer What to check If it fails
Can Google reach my pages? Crawling Crawlable links, robots.txt, rendering, mobile/desktop parity Pages never enter the process
Does it understand and choose the right version? Indexing noindex, canonicals, duplicates, structured data The page does not appear, or another version does
Can the person use it? Experience Core Web Vitals, accessibility, forms, mobile They arrive but do not progress or cannot act

The layers are cumulative: a failure in the first one invalidates the effort in the next.

Crawling and indexing: what has to be right before anything else

Links must be links. Google’s JavaScript documentation explains that Google crawls, renders and indexes in phases, and that it can only discover links that are <a> elements with an href attribute. Menus or buttons that navigate through JavaScript events without a real href can leave pages undiscovered. For single-page applications, Google recommends using the History API rather than URL fragments.

Robots.txt controls access, not indexing. According to Google, robots.txt is used mainly to avoid overloading your site with requests and is not a mechanism for keeping a page out of Google; for that, you use noindex or password protection. The classic mistake is twofold: blocking in robots.txt what you meant to exclude (the page can still appear if other sites link to it), and leaving a noindex from the development phase on pages that should be indexed.

The mobile version is the one that counts. Google uses the mobile version of content, crawled with its smartphone agent, for indexing and ranking. If your mobile version has less content than the desktop one, that content may not count. Titles, meta descriptions and structured data must match across both versions. Google considers responsive design the easiest pattern to implement and maintain.

Errors that cost customers:

  • Service pages carrying a noindex inherited from a staging template.
  • Menus that depend on JavaScript without real links, hiding whole sections from crawling.
  • Key content present only in the desktop version.
  • A migration or redesign that changes URLs without redirects, wiping out the history those URLs had accumulated.

Canonicals and duplicates: guide Google, don’t order it

When several URLs show the same content (with parameters, with and without a trailing slash, http and https versions), Google chooses a canonical version. Its documentation lists the signals in order of strength: redirects are a strong signal, rel="canonical" is also a strong signal, and inclusion in a sitemap is a weak signal. They can be combined. One nuance matters: none is mandatory, and Google may decide on its own.

The practical consequence is consistency. A canonical pointing to a URL different from the one you link to and declare in the sitemap sends contradictory signals. The rule is that internal links, the sitemap, the canonical and the redirect should all point to the same preferred URL.

Structured data: describe what is already on the page

Structured data helps Google understand content and can enable appearance features in results. Google’s guidelines set clear limits:

  • Visible content only. Don’t mark up content that is not visible to readers of the page.
  • JSON-LD is Google’s preferred format.
  • No guarantees. Google does not guarantee structured data will show up in search results, even if the markup is correct.
  • Manual action risk. Misleading markup can trigger a manual action that removes rich result eligibility, without affecting regular ranking.

The working criterion on a business site: mark up what exists (organization, contact details, breadcrumbs, real products) and validate the result before publishing. Don’t mark up reviews that are not on the page or invent ratings. For businesses with a local presence, the guide to local business marketing covers LocalBusiness data.

Core Web Vitals: the current thresholds

Core Web Vitals measure three aspects of real experience. These are the thresholds web.dev publishes, evaluated at the 75th percentile of page loads and segmented by mobile and desktop.

Core Web Vitals: web.dev thresholds
Metric What it measures Good Needs improvement Poor
LCP (Largest Contentful Paint) Load speed of the main visible element 2.5 s or less Between 2.5 and 4.0 s More than 4.0 s
INP (Interaction to Next Paint) Responsiveness to clicks, taps and keyboard input across the whole visit 200 ms or less Between 200 and 500 ms More than 500 ms
CLS (Cumulative Layout Shift) Visual stability: unexpected layout shifts 0.1 or less Between 0.1 and 0.25 More than 0.25

Source: web.dev articles on Core Web Vitals, LCP, INP and CLS (accessed October 9, 2026). INP replaced First Input Delay (FID) as a Core Web Vital on March 12, 2024; guides that still mention FID are out of date.

Four points for using them well.

Field data versus lab data. Lab data is collected by loading the page in a controlled environment; field data comes from real users. web.dev notes that field data, which Chrome tools generally get from the Chrome User Experience Report (CrUX) over 28 days, is what you should use to prioritize, and is what the Core Web Vitals assessment relies on. A perfect lab score with poor field data is a real problem.

How they relate to ranking. Google says Core Web Vitals are used by its ranking systems, and also that it “always seeks to show the most relevant content, even if the page experience is sub-par.” In other words: they are not a shortcut to outrank a competitor with better content, but a poor experience is a disadvantage that does not pay for itself.

Measure by template, not by site. A site has families of pages (home, service, article, product, form). Prioritize the ones that concentrate visits and commercial actions, not the domain average.

The typical causes are known. Heavy or poorly sized images in the main element (LCP), third-party scripts and long JavaScript tasks (INP), images, ads or banners without reserved space (CLS). Per-page diagnosis with field data avoids optimizing blindly.

How to check your situation without being technical

Three free Google tools answer the basic questions, with limits worth knowing.

  • Page indexing report (Search Console). It shows how many pages are indexed and why others are not (noindex, robots.txt blocks, duplicates, server errors). Google clarifies that you should not expect every URL to be indexed, only the canonical ones: what matters is that your commercial pages are.
  • Core Web Vitals report (Search Console). It uses field data from the Chrome User Experience Report, split by mobile and desktop and grouped by URL. It includes only indexed URLs and omits those without a minimum amount of data, so a low-traffic site may not appear.
  • PageSpeed Insights. It combines field data (from the previous 28 days) with Lighthouse lab data. According to Google, lab data is useful for debugging but may not capture real-world bottlenecks.

Accessibility: the standard is WCAG 2.2

Accessibility is not an add-on for a marginal audience: it determines whether everyone, including people using screen readers, keyboards or magnification, or with motor limitations, can read your site and complete an action. And many of its requirements coincide with what improves conversion for everyone.

The reference standard is WCAG 2.2, published as a W3C Recommendation on December 12, 2024, with conformance levels A, AA and AAA. WCAG 2.2 adds nine success criteria, including some with direct impact on commercial sites:

  • Target Size (Minimum), 2.5.8, level AA: touch targets should not be so small that they are hard to press.
  • Focus Not Obscured (Minimum), 2.4.11, level AA: the keyboard-focused element must not be hidden, for example by a sticky banner.
  • Dragging Movements, 2.5.7, level AA: there must be an alternative to dragging.
  • Accessible Authentication (Minimum), 3.3.8, level AA: logging in should not require remembering or transcribing.
  • Redundant Entry, 3.3.7, level A: don’t ask for the same information twice in one process.
  • Consistent Help, 3.2.6, level A: help appears in the same place on every page.

WCAG 2.2 also removes criterion 4.1.1 (Parsing), which had become obsolete. The W3C notes that content conforming to WCAG 2.2 also conforms to WCAG 2.0 and 2.1, and recommends applying 2.2 even where the rules that apply to you cite an earlier version.

How the real web looks. The WebAIM Million 2026 report, which automatically analyzed the home pages of one million sites in February 2026, detected WCAG 2 failures on 95.9% of them, with an average of 56.1 errors per page. The most common were low-contrast text (83.9%), images missing alternative text (53.1%) and form inputs without labels (51%). The 2025 average had been 51 errors per page (a 10.1% increase). Pages with ARIA attributes averaged more errors (59.1) than pages without them (42): that is an association, not proof that ARIA causes errors. WebAIM stresses that automated detection does not prove a page is accessible: actual conformance is likely lower. What matters for a business is that several of the most common failures (contrast, unlabeled form fields, empty links and buttons) hit exactly the buttons, forms and calls to action that produce customers.

The business case, with caution. The W3C’s business case cites benefits such as extending market reach, enhancing brand and minimizing legal risk, with links to studies and court cases. It is a reasonable argument, but not a conversion promise. Legal obligations vary by country and sector: check with legal counsel which rules apply to your activity.

From technical SEO to conversion: what evidence exists

Caution matters here more than in any other section. Two studies published by web.dev, both of large companies:

  • Vodafone, 2021. In an A/B test on a landing page that split paid-media traffic 50/50 between an optimized version and a baseline, with no other visual or functional differences, the optimized version had a 31% better LCP in the field and produced 8% more sales, a 15% uplift in lead-to-visit rate and 11% in cart-to-visit rate.
  • Renault. A correlation analysis (not an A/B test) of more than 10 million landing-page visits across 33 countries, between December 2020 and March 2021, derived with linear regressions that a 1-second LCP improvement can be associated with 14 percentage points lower bounce rate (for pages with LCP under 1.6 s; about 5 points above that) and 13% more conversions, defined as completed lead forms.

How to read them. The Vodafone study is a controlled experiment, the stronger of the two, but it is a single case from a large company with a specific page and specific traffic. Renault’s is a correlation: fast pages may differ from slow pages in other respects. Neither proves your site will see that effect. What they do support is a reasonable hypothesis: on high-traffic pages with a poor experience, improving it may raise conversion.

How to check it for your case. Compare the conversion of your highest-traffic pages with their field performance. If pages with poor LCP or INP clearly convert worse for the same type of traffic, there is a hypothesis worth testing. If there is no difference, the bottleneck is elsewhere, and the diagnosis in why your website gets traffic but no leads helps you find it. To structure conversion analysis on a B2B site, see CRO: what it is and how to apply it.

How to prioritize: business impact against effort

The list of possible technical improvements is almost endless; the budget is not. An order we recommend at Maccam Network:

  1. Access blocks on commercial pages. An accidental noindex, a misconfigured robots.txt, uncrawlable links, wrong canonicals. It is the cheapest to fix and the one that can cost the most.
  2. Contact routes that work. Forms that submit, phone numbers you can tap, messages that arrive. Verify with real tests, not tools.
  3. Experience on key templates. Core Web Vitals on the page families that concentrate visits and actions, using field data.
  4. Accessibility at conversion points. Contrast, labels, target size and focus on forms, buttons and menus.
  5. Structured data and detail improvements. Useful and low-risk, but rarely the first lever.
  6. Ongoing governance. A site degrades with every content change, plugin or third-party script. Someone who regularly reviews the indicators prevents discovering problems through a drop in results.

What not to do. Chasing a tool’s 100 instead of field metrics; optimizing a low-traffic page while the contact page fails; adding third-party scripts without measuring their cost; or expecting a technical change to compensate for a weak message or offer, which are a different layer.

Next step

A useful technical audit does not deliver a list of a hundred warnings, but a work order tied to pages and business outcomes. At Maccam Network we fold it into our web development and SEO work, and you can read about the approach in our SEO methodology. If you want to talk about your site, get in touch.

Sources verified as of October 9, 2026. We have not verified legal accessibility obligations (they vary by country and sector) or the figures of third-party cases other than the two web.dev cases cited.

Sources

Preguntas frecuentes

According to web.dev, a page performs well if its Largest Contentful Paint (LCP) occurs within 2.5 seconds, its Interaction to Next Paint (INP) is 200 milliseconds or less, and its Cumulative Layout Shift (CLS) is 0.1 or less. They are assessed at the 75th percentile of page loads, segmented across mobile and desktop. INP replaced First Input Delay as a Core Web Vital on March 12, 2024.

No. Google's documentation says Core Web Vitals are used by its ranking systems, but that Google seeks to show the most relevant content even if page experience is sub-par, and that good scores do not guarantee top results. Their value is twofold: not losing ground to a poor experience, and improving the experience of the people who do arrive.

No. According to Google, robots.txt is used mainly to avoid overloading your site with requests and is not a mechanism for keeping a web page out of Google. To keep a page out of the index, use a noindex meta tag or response header, or password-protect the page.

The reference standard is WCAG 2.2, a W3C Recommendation since December 12, 2024, with conformance levels A, AA and AAA. Many teams treat AA as the practical target for commercial sites; AAA is the most demanding and is not always achievable across all content. If your business is subject to accessibility regulation, check the applicable requirements with legal counsel.

There are documented cases, but no universal rule. In an A/B test, Vodafone found that a version of a landing page with a 31% better LCP produced 8% more sales; Renault observed a correlation, across millions of visits to its landing pages, between faster LCP and better bounce and conversion rates. These are studies of specific companies with their own traffic and context. The reliable way to know for your site is to measure conversion by page against its real performance.

With whatever keeps commercial pages from being found, indexed and working: crawl blocks, pages mistakenly set to noindex, wrong canonicals, broken forms. Then the experience on the templates that carry the most traffic and conversions, and finally the detail improvements. Prioritize by business impact and effort, not by the number of warnings a tool produces.

Newsletter

New ideas, analysis and research — directly to your inbox.

Subscribe to receive new Insights publications and other selected content from Maccam Network. No spam. Unsubscribe at any time.

By subscribing you agree to receive communications from Maccam Network.

In this ecosystem
Hub SEO & Visibility Methodology SEO Methodology Service Web Development
Published by

Maccam Network Editorial Team

Editorial Team, Maccam Network

The Maccam Network Editorial Team researches, analyzes, writes, edits and verifies the institutional content of the Maccam Library. All content published under this byline integrates primary sources, documented professional experience and editorial review before publication.

View editorial profile →

Shall we talk about your business?

Let's talk about what your business needs.

A 30-minute conversation is enough to understand the context, identify the problem and see if we are the right team to help you.

Free consultation via WhatsApp See contact form