UX moves your rankings through what visitors do after they click, and the work worth funding first is the work that pays SEO too. Search systems measure parts of your page directly, but mostly they see whether people stay, go deeper, or return to the results and pick a competitor. Most teams get that order wrong, because the highest-return work sits in the overlap rather than inside either budget. I’m Szymon Słowik, and I’ve run SEO audits with UX as a core dimension since 2015.
TL;DR
- Search engines grade a few parts of your page directly and infer the rest from behaviour. Speed and intrusive layouts they measure. The rest of the user experience they read from clicks, quick returns to the results page and the next query the visitor types.
- Core Web Vitals are close to table stakes. In July 2025, 48% of mobile sites and 56% of desktop sites passed all three thresholds, up from 36% of mobile sites two years earlier. Passing still beats failing, but in competitive results it rarely separates you from anyone.
- Most UX-versus-SEO arguments are really information architecture problems. When the structure of the site is right, the two sets of recommendations mostly agree on their own.
- Fund the work that pays both sides before the work that pays one. An architecture rebuild returns traffic and conversion from a single implementation cost. A link campaign returns traffic alone.
- Two clocks run at the same time and stakeholders only watch one. Layout and copy changes move conversion within weeks. Ranking effects from better engagement take months, so set that expectation before the work starts.
What user experience means in SEO, and how it differs from UI
In SEO, user experience means everything that decides whether a visitor arriving from search can finish what they came to do. How fast the page loads, and how easily they find the answer. Whether the content matches the query they typed, and whether they trust you enough to act on it.
The user interface is the visual layer, and it is not the same thing. Buttons, colours, typography, layout – UI is what you see, UX is what you go through. A page can look gorgeous and still be miserable to use. I’ve audited sites with award-winning visual design where visitors could not work out how to request a quote and could not find pricing at all, the designer won a prize, and the sales team kept wondering why the contact form stayed empty.
UX is also not a design refresh. This is the misconception I run into most often with SEO teams. They hear UX and picture new fonts, an updated colour palette, maybe some illustrations, which is a UI project. UX starts from what the visitor is trying to accomplish and what stands between them and that outcome.
And it is wider than usability testing. Testing is one research method inside the discipline, not the discipline itself. UX in a search context starts at the results page and ends at task completion. How the page appears in the snippet, how fast it renders, whether it answers the actual query, whether the visitor believes you – all of it produces the behaviour search systems record.
Four terms get used interchangeably in these conversations, and separating them is what makes the budget argument tractable.
| Term | What it covers | Who usually owns it |
|---|---|---|
| UI (user interface) | The visual and interactive surface: layout, type, colour, components, states | Design |
| UX (user experience) | Whether the visitor can complete the task: architecture, hierarchy, cognitive load, trust, friction | Product or design research |
| SXO (search experience optimization) | The tactical overlap of SEO and UX on the page: speed, readability, matching intent, reducing friction | SEO, in practice |
| UX SEO integration | The operating model around that overlap: who decides, what gets funded, what both teams are measured on | Nobody, in most companies |
That last row is the gap this article is about. The tactical overlap is well covered by everyone, while the operating model around it almost never is, and that is where the money leaks.
How user experience changes your rankings
User experience changes your rankings indirectly, through the behaviour it produces after somebody clicks your result. A visitor picks you from the results page, and what happens next either confirms that choice or reverses it. Clicking deeper into the site is the clearest form of confirmation there is, and search systems aggregate those outcomes across millions of queries to adjust what they show next time.
The mechanism has a name. Google’s click system, NavBoost, was described by Google’s own witnesses under oath during the US antitrust trial, and matching fields appear in the 2024 API documentation leak. I treat the leak as a working model rather than a specification, for reasons I set out in my read of which leaked ranking signals actually matter. The testimony is a different class of evidence, and that part is on the record. It is worth being precise about what a search system records from a visit, and what it never sees.
| What a search system can observe | What it cannot observe | What that means for you |
|---|---|---|
| Whether your result was clicked, and from which position | Whether the visitor liked the design | The snippet is part of the experience, not a separate SEO asset |
| How quickly the visitor came back to the results page | Why they came back | A fast return reads the same whether the page was slow, wrong or untrustworthy |
| Whether the next query was a refinement of the same need | Whether the answer was on the page but buried | Burying the answer costs you the same as not having it |
| Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift, from real visits | Cognitive load, trust, perceived credibility | The measurable layer is the shallow one, so do not stop there |
| Layout patterns it has explicit rules for, such as intrusive interstitials or content pushed below the ads | Whether the layout actually serves the task | A page can pass every layout rule and still lose the visitor |
The consequence is uncomfortable for anyone used to thinking in ranking factors. A page can win position on strong content and site-level authority, then give that position back over the following months because visitors keep bouncing off it. I’ve watched this happen to pages that were technically immaculate and had confusing layouts, buried calls to action, or content answering a slightly different question than the one being asked.
Here is the check worth running this week. Take your twenty highest-impression landing pages in Search Console, and compare click-through rate and average position over the last two quarters. Pages holding position while their click-through rate slides are being passed over in the results. Pages losing position while impressions hold are the ones where behaviour after the click is the likely cause, and those are the pages to put in front of a designer rather than a link builder.
Which UX factors move rankings, and which are only hygiene
Speed and mobile layout are hygiene, while intent match, information architecture, content hierarchy and trust signals are where rankings are most often won or lost. Every article on this topic lists the same five factors ranked by nothing, as if they carried equal weight: speed, mobile layout, navigation, intent matching and readability. They do not carry equal weight, and two things the standard five leave out, trust at the point of decision and accessibility, belong on the list as well. Intent match is where I would start, because it fails most often on pages built from a volume number instead of a real question, which is the habit I take apart in the piece on keywords with little or no recorded search volume.
| Factor | What it changes | Floor or edge | Where it usually fails |
|---|---|---|---|
| Core Web Vitals | Whether the page is slow enough to lose visitors before it renders | Floor – about half the mobile web now clears it | Third-party scripts added after the last performance project |
| Mobile layout | Whether the majority of your visitors can use the page at all | Floor | Tables, forms and navigation that were only ever tested on a laptop |
| Intent match | Whether the content answers the query that brought the visitor | Edge – the largest single lever in most projects I see | Pages built from a keyword rather than from a question |
| Information architecture | Whether visitors and crawlers can both find their way to the right page | Edge – and it is shared with SEO | Structure inherited from an org chart or an old CMS |
| Content hierarchy and scannability | Whether the answer is reachable in seconds, and extractable as a passage | Edge | Long undifferentiated prose with no heading logic |
| Accessibility | Whether assistive technology and crawlers can reach and parse the same content | Floor – and in the EU a legal one | Handled as a late compliance task instead of built in |
| Trust signals at the decision point | Whether the visitor believes you enough to act | Edge – and usually unowned | Author, credentials and proof placed on an About page nobody visits |
Accessibility sits in that floor layer too, and it is the one row with a deadline attached. Alt text, semantic headings, readable contrast and keyboard-navigable menus let assistive technology and crawlers read the same page for the same reasons. Since 28 June 2025, the European Accessibility Act has applied to e-commerce and consumer services across the EU, which turns part of that work from a preference into an obligation.
The Core Web Vitals row deserves its numbers, because the usual framing is a couple of years out of date. Compliance stopped being a differentiator a while ago.
| Year (July data) | Mobile sites passing all three | Desktop sites passing all three |
|---|---|---|
| 2023 | 36% | 48% |
| 2024 | 44% | 55% |
| 2025 | 48% | 56% |
Those figures come from the 2025 Web Almanac performance chapter, which reads Chrome’s field data rather than lab scores. Half the mobile web now passes. If your integration plan stops at making pages load faster, you have bought yourself parity with the median site and nothing beyond it.
So the allocation question answers itself. Get the floor rows to passing, then treat them as maintenance rather than as a growth project. What does that leave you? Intent match, architecture and trust, which is where the real distance between you and the result above you sits, and where a competitor with a weaker product can still take your position.
Where UX and SEO conflict, and how to settle it
UX and SEO collide over the same five things in every project: content density above the fold, internal linking, page length, navigation depth and the hero. I stopped treating those as case-by-case judgement calls and wrote the rule down in advance. It resolves them faster and takes most of the politics out of the room, because the team that loses a call knows why before the call is made.
| Conflict | What UX wants | What SEO wants | The rule I use |
|---|---|---|---|
| Content density above the fold | A clean hero and minimal friction | An opening paragraph that states the topic and anchors the entities | Conversion wins while organic click-through rate holds. If click-through rate is sliding, SEO takes the space. |
| Internal linking density | Fewer visible links, calmer interface | Deep crawl paths and contextual clusters | Links belong in the body copy where they help the reader, not bolted into the interface as widgets. |
| Page length | Short, scannable, task-oriented | Enough depth to cover the topic and survive passage extraction (a system lifting one section as the answer) | Layer it. The answer sits above the fold, the depth sits below it. |
| Navigation depth | Flat, two clicks to anything | A hierarchy that matches the topic structure | Information architecture settles both. If the structure is right, this argument does not occur. |
| Hero image against hero text | Visual impact and brand storytelling | Crawlable text with the H1 in the first viewport | Test it, with performance monitored. A visual hero over real semantic markup usually satisfies both. |
Look at the fourth row again, because it generalises. Most of these disputes dissolve once both teams accept that how the site is organised around topics and entities is a shared foundation rather than an SEO deliverable. When the two sides genuinely diverge after that, it is usually a structural problem dressed up as a taste disagreement.
I tell clients to write their own version of this table before the next redesign kicks off, and five rows is enough to start. The value is not in my rules, it is in having the argument once, in a calm room, rather than every sprint.
What to fund first when UX and SEO compete for the same budget
Fund the initiatives that pay both sides before the ones that pay one, because the highest-return work carries a single implementation cost and returns twice. UX and SEO usually arrive as separate line items, approved by different people, measured against different benchmarks. A marketing director reading that budget sees two competing claims on one pool, which is the framing that produces the bad decision.
| Type of investment | Example | What it returns |
|---|---|---|
| SEO only | A link acquisition campaign | Traffic volume, with no lift in conversion |
| UX only | Redesigning the onboarding flow for logged-in users | Conversion rate, with no lift in traffic |
| Both | Restructuring the information architecture | Traffic, conversion and crawl efficiency |
| Both | Rebuilding content design around a clear semantic structure | Rankings, engagement and snippet capture |
| Both | Fixing Core Web Vitals, once | Page experience compliance and lower abandonment |
Once the dual-impact work is funded, allocate what is left to whichever dimension is the current bottleneck. Traffic strong and conversion weak points the remaining budget at UX. Conversion healthy and organic traffic flat points it at SEO. That is a decision rule, and it is much more useful than “it depends on your situation”.
One honest caveat. This works only when somebody can see both budgets at once, and if nobody in your organisation has that view, the portfolio logic is unusable. Fixing the visibility problem then comes before fixing the allocation, which is often the first thing an outside pair of eyes is actually buying you. My broader take on what an SEO strategy actually consists of covers the same failure at company level, and if the market itself is unfamiliar, what to check before committing budget to a new market is the other half of that question.
How to run a UX SEO audit as one assessment
A UX SEO audit assesses the same pages against both sets of criteria in one pass, so that a page failing on rankings and a page failing on engagement can be recognised as the same page with one root cause. Most companies I work with have never done this. They have an SEO audit covering technical health, on-page work and links, and separately a UX review with a heuristic evaluation (an expert walkthrough against usability principles) and maybe some user testing. Two reports, two owners, two audiences who never compare notes.
I have run several dozen audits that cross SEO with UX, brand, content and paid search. The recurring finding is dull and expensive. The SEO report lists pages with weak rankings, the UX report lists pages with weak engagement, and the large overlap between those two lists goes unremarked because nobody puts them side by side.
One case makes the overlap concrete. On an insurance company’s Polish site, a content quality and pruning programme moved blog keywords in the top three from 3,402 to 4,399. The pruning was not only a search play, because removing weak pages also cleaned up the experience and concentrated engagement on the pages that actually helped people. Queries matching specific product pages went from 80 to 139, once visitors stopped bouncing between near-duplicate content.
- Pull one page inventory, not two, and attach both the search metrics and the behavioural metrics to every row.
- Assess the information architecture once, against both crawl paths and visitor wayfinding. It is the layer where the two disciplines are literally the same work.
- Check content design against the query that earns each page its traffic, not against a word count. The answer needs to be reachable in the first screen and deep enough below it to be worth staying for.
- Establish the technical baseline, including how much JavaScript rendering costs you in both perceived speed and crawlability.
- Classify every page by traffic and conversion together, then read the classification as a work queue.
Step four hides a trap worth naming. A rendering problem looks like a performance problem to the UX side and like a crawling problem to the SEO side, and each team fixes its own half. I took apart one version of this in a case study on a new portal Google would not index, where the page was fine for humans and unreadable for the crawler. If you want the shape of the wider assessment, my SEO audit approach sets out the layers I work through and how they connect.
Classifying every page by traffic and conversion
Once you have organic traffic and conversion on the same row, every page falls into one of four groups, and each group has a different owner.
I run this early in every engagement because it settles the argument about where to start without anyone having to win it. Your benchmark pages show what integrated success looks like on your own site, in your own market, which is more persuasive internally than any case study I could hand over.
Measure the outcomes that only make sense with both disciplines in the frame, starting with organic-attributed revenue for each landing page. Measured separately, the same week produces two contradictory readings. Organic sessions rose and conversion rate fell – an SEO win or a UX failure? With siloed metrics that question has no answer, which is why it gets settled by whoever presents last.
| What you are measuring | The UX side of it | The SEO side of it | What the pair tells you together |
|---|---|---|---|
| Quality of engagement | Session duration, scroll depth, pages per session | Time before returning to the results page | Whether visitors are finding and consuming what they came for |
| Efficiency of conversion | Conversion rate, task completion rate | Revenue and leads attributed to organic | The quality of the traffic, rather than the volume of it |
| Technical performance | Core Web Vitals from real visits, mobile usability | Page experience compliance | Whether the foundation is stable enough for either team to build on |
| Return behaviour | Returning visitor rate, saved items | Growth in branded search volume | Whether trust and recall are accumulating over time |
| Effectiveness of content | Interaction rate, engagement with calls to action | Click-through rate from the results page, snippet capture | Whether the content satisfies intent at the snippet and on the page |
The row that matters most is the second one, and it is the row most companies cannot produce. Organic-attributed revenue broken down by landing page tells you which pages carry their weight across both dimensions, and it converts this whole discussion from a craft argument into a business one. If you can only add one number to your reporting this quarter, add organic-attributed revenue by landing page.
Where your organisation stands on UX SEO integration
Your organisation sits at one of five levels of UX and SEO integration, and each one has to be stable before the next will hold. I’ve seen enough companies attempt this at the wrong level to be confident about the sequence. Running shared measurement while the two teams still work in full isolation produces meetings rather than results.
| Level | How it works day to day | What breaks at this level |
|---|---|---|
| 0. Full silo | The two teams operate independently, with no shared meetings, metrics or roadmap visibility | Conflicting changes ship in the same week. Design sprints undo ranking gains and technical fixes undo design decisions. |
| 1. Shared awareness | Each team knows the other exists and they talk when something breaks | Coordination is triggered by incidents. Both teams still optimise for their own targets. |
| 2. Shared measurement | Both teams report against a common set of metrics, and reviews include the combined outcome | Measurement agrees but planning is still separate. Conflicts surface earlier and resolve slowly. |
| 3. Shared planning | Sprint planning is joint, roadmaps are built together, budget proposals are co-authored | Compounding starts here. What friction remains is usually tooling rather than strategy. |
| 4. Integrated system | Integration is part of the operating model, with no separation in planning, budgeting or measurement | The risk shifts from coordination failure to complacency, because the system works and nobody asks whether it could work better. |
Most companies I work with sit between level 0 and level 1. The ones that come looking for outside help are usually at the point where level 1 has stopped being enough, and they can see the problem without having the internal structure to fix it. I would not push a team straight from level 0 to shared measurement, though whether level 1 needs one quarter or three is a genuine judgement call, and I get it wrong sometimes.
Place yourself on this table before you plan anything, and if you land on level 0, your next move is a single shared project rather than a reorganisation. I have seen this pattern across enterprise work in travel, banking, B2B software and market research, in Poland and in international teams. The knowledge is almost always already in the building. Somebody in UX knows exactly why the page underperforms, somebody in SEO knows exactly which page should rank, and they sit in different departments.
Three projects where UX and SEO integration decides the outcome
Three projects do the visible damage: a replatforming project, a plateau after two good years of tactical SEO, and a new site being built from nothing. The playbook above reads cleanly and real organisations are messy, so this is where the gap actually costs money. They differ mainly in when the work has to start, and in what being late costs.
Replatforming and site migration
A replatforming project splits three ways, with development focused on feature parity, SEO deep in redirect mapping, the design team rebuilding the front end in Figma, and nobody owning the intersection. The site then launches technically better and loses organic traffic, because nobody scoped the overlap. The new structure does not match the paths that were being crawled, and the new design does not preserve the behaviour that was feeding positive signals. The fix is unglamorous and rarely happens: the integration starts during migration scoping, not after the traffic drops.
The plateau after two good years of growth
A plateau arrives after rankings improved and traffic grew, and then more content and more links stop moving anything. In my experience this often traces to a ceiling on the experience rather than on the content. The pages rank, they get the click, and visitors leave unsatisfied, which suppresses further gains. A single-discipline audit will not find that ceiling, because each report reads acceptable on its own.
Greenfield builds with no legacy
A new site with no legacy is the easiest case for integration and the most frequently wasted one. Founders tend to pick a side: a beautiful product site with no content architecture, or a content-heavy site built on a blog template, and neither compounds. Building both dimensions in at the start costs almost nothing extra and is expensive to retrofit later. That is the whole argument for doing the strategy work before the build.
If one of these three describes your next two quarters, that is your trigger to put the integration on the plan now rather than after the fact. The migration case in particular has a hard deadline attached to it, and the cost of being late is measured in traffic you already had.
UX debt and how it shows up in rankings
UX debt behaves like technical debt, and framing it that way is the fastest route to a budget conversation with people who do not care about design. Engineering leaders already accept that shortcuts accrue interest, and the same argument works for experience. Four forms of it turn up in almost every audit I run, and each one sends budget to the wrong fix.
| The debt you are carrying | What the visitor does about it | What gets funded instead |
|---|---|---|
| Confusing navigation | Fails the task and leaves | More content, on the theory that coverage is missing |
| Poor content hierarchy | Leaves early, because the answer was not where they looked | Keyword work on a page whose answer was already there |
| No trust cues at the decision point | Returns to the results page to check somebody else | Links, against a credibility gap that links cannot reach |
| Slow mobile experience | Abandons before the page settles | A desktop-first redesign that never touches the problem |
Every row in that table runs through the behavioural loop described earlier, and surfaces months later as positions that no longer hold. By then the connection to the original design decision is invisible, which is why the third column keeps getting funded. Big brands appear to get away with more of this, and partly they do, because recognition absorbs a lot of friction. Treat that as an argument for fixing your own experience rather than for envying their budget.
One more thing about timing, and I want to label it as an operational hypothesis rather than something I can prove. The decline from UX debt tends to become visible around a broad core update rather than arriving gradually. The debt accumulates quietly while a page keeps its position, and a broad reassessment is what makes it legible, which is why the drop feels sudden to everyone in the room.
UX and SEO in AI search
In AI search the same page qualities decide whether you get quoted, which makes this the rare shift that asks nothing new of you. AI Overviews (Google’s generated answer block above the blue links) and assistants pull passages that stand on their own. In my experience a page that buries its answer under a cookie banner and three stock photos rarely gets cited, however strong its link profile looks.
Clean heading structure matters because extraction depends on it. A retrieval system needs to find where an answer starts and ends, and your headings are the clearest boundary markers a retrieval system has to work with. I go through that mechanism properly in the piece on how Google’s search pipeline moves from retrieval to AI answers, and the acronym confusion around it in why AIO, GEO and AEO are mostly old principles renamed.
The alignment is convenient and worth saying plainly. Short paragraphs, answers stated up front, honest headings, structured data and fast rendering reduce friction for a human reader and for a retrieval system at the same time. A page built for good experience is largely built for citation already. What it still needs is clear topical focus and a recognisable presence off your own site, because being extractable does not help if nothing points at you.
Before you fund a separate AI visibility workstream, measure whether you have a problem. I set out a way to do that in my method for measuring AI visibility. In most cases the answer is that the same integration work serves both surfaces, and a separate track would duplicate it.
Where to start with UX and SEO integration on your own site
Start by finding the pages that fail on both dimensions at once, because those are the cheapest place to prove the case internally. Cross your organic traffic with your conversion data, take the pages sitting in the weak-weak corner of Figure 2, and fix one of them properly with both teams in the room. Measure it together. Then use that single result as the argument for doing it more widely.
Underneath all of this sits one claim, and it is the one I would defend hardest. Organic growth is a system rather than a stack of independent tactics. That is the reasoning behind the BUXS framework (my own method for planning brand, experience and semantics as one system), and behind the way I treat search as the strategic core of the organic ecosystem. Brand, experience and semantics either reinforce each other or they quietly cancel out.
None of this is a new position for me. In late 2015 I wrote a series for the Polish marketing magazine Marketer+ with Piotr Socha, a UX strategist, on optimising websites and online shops. He argued the experience side and I argued the search side, and part one opened on sales being traffic multiplied by conversion rate, with information architecture as the work that comes before any advertising spend. That ran before engagement, goal completion, user journey and SXO were standard vocabulary in SEO.
If you would rather talk it through against your own numbers than work from a template, send me the project and the problem and we will put an hour against it on a paid consulting call, 250 USD for the hour. You get the reasoning, the options and a written summary afterwards, and that summary is yours to use whether or not we work on anything further. Book a consulting call here, or read first about what working with a small specialist outfit actually looks like if you are still deciding what kind of help you need.
FAQ: UX and SEO
Not quite. SXO describes the overlap between search optimization and experience on the page, and it stays tactical: faster loading, better readability, less friction. Integration is the operating model around that overlap. It covers who decides when the two disciplines disagree, which budget pays for the work, and what both teams are measured on.
No. User testing, journey mapping, heuristic evaluation and accessibility work are their own discipline with their own methods, and integration does not absorb any of them. What changes is where the findings land. Research output starts informing content architecture, internal linking and targeting instead of sitting in a file nobody on the search side opens.
Two clocks run at once. Conversion effects from layout, copy and call-to-action changes usually appear within two to four weeks. As a rule of thumb I plan three to six months on the ranking side, because the engagement pattern has to accumulate. Teams that judge the work at six weeks conclude it failed.
Click behaviour is the documented one. Whether your result gets clicked, how quickly the visitor returns to the results page, and whether the next query repeats the same need. Core Web Vitals count as well, but they now separate you from almost nobody, because roughly half of the mobile web passes them.
Carefully, and in that order. The real risk is changing URLs, navigation or heading structure during a redesign without telling the search side first. Run tests on isolated sections, watch performance metrics through every single cycle, keep redirect maps current, and crawl the staging environment before any full-site release reaches production.
Small companies often have the advantage here. When one person decides both, the worst coordination problems rarely arise, and many already operate near the top of the maturity table without noticing it. The levels matter most for mid-market and enterprise organisations, where specialisation put experience and search into separate departments with separate budgets.
They matter as a floor. In July 2025, 48% of mobile sites and 56% of desktop sites passed all three thresholds, against 36% of mobile sites two years earlier. Failing still costs you visitors. Passing buys parity with the median site, so treat it as maintenance rather than as a growth project.
The know-how input, insights and conclusions: Szymon Słowik. Research and drafting support: AI-assisted BUXS engine. Reviewed, corrected and finalized: Szymon Słowik.
Created by Szymon, edited with an LLM… see any difference? 🙂
Pozdrawiam serdecznie!