I built the first version of this site in Webflow and I enjoyed building it there. Then whatever I wanted to make kept needing custom code, which suited me fine since I like writing code about as much as I like designing. But it kept needing more of it. By the time I looked properly at what was mine versus what the builder was doing, roughly 90% of the site was CSS and JavaScript I'd written myself, sitting on top of a subscription.
Maintenance is what decided it in the end. Webflow would ship something natively and a piece of my code would go redundant, or start fighting the new feature. I was keeping workarounds alive for problems that had stopped existing. Localization, which I wanted, was another paid add‑on on top of that.
So, 90% mine already. I figured I might as well write the last 10%, own all of it and stop paying for permission. The last 10% was of course the difficult one.
This article is about what that rebuild had to do with search. SXO, search experience optimization, is the idea that ranking and user experience are one job instead of two, and it usually gets explained as five pillars. Those five pillars turn out to be a fair description of where my time went. So rather than explain the theory, which you can read anywhere, I'll go through them as one real site, including the two places where I had my own work wrong.
Why SXO, not just SEO
Where SEO stopped being enough
I've spent a fair amount of my career on the losing side of this. A particular phrase had to appear in the title, in that order, even when it didn't fit the line and broke the design it was drawn for. A keyword has to sit somewhere prominent, so it goes somewhere prominent, and the sentence around it ends up reading like it was written for a machine, because it was. The version I minded most was a keyword inside a button, where you have three or four words to tell somebody what happens when they click and you're spending two of them on a crawler.
That made a kind of sense while a search engine could only read the page. It counted keywords, followed links and guessed at the rest, so you wrote for the guess. If that made a label harder to read at a glance, or stopped it describing what pressing it would actually do, that was the price of ranking and somebody had decided it was worth paying.
It stopped being only able to read the page a while ago. A search engine now has some idea whether someone stayed or bounced back to the results and clicked the next one down, and whether the layout shifted under their thumb while it was still loading. Both of those measure experience, and both feed the ranking.
So the split was real, and it has closed. The two sides needed different tooling and different people arguing for them, because a search engine genuinely couldn't see the thing the designers were arguing about. It can see a fair amount of it now, and the arguments I used to lose have quietly become arguments about ranking as well.
SXO gets broken into five pillars: speed, user experience, content, search intent, and watching what happens afterwards. I'll take them in that order. Not as five definitions, which are a search away, but as a report on what each one turned into on one specific site.
Pillar 1 — Speed and mobile
Most of what makes this site quick, I didn't do for speed.
The fonts are the clearest case. There are nine files loading off my own server, which reads on a performance checklist as a considered decision, and it wasn't one. I chose those typefaces while I was building the brand, because they were the right typefaces, and a licensed font lives on your own server whether you care about milliseconds or not. The speed came free with a decision I made for other reasons entirely.
The analytics went the same way. I'm not running Google Analytics, and the reasons, roughly in the order I thought them:
- I'd had a miserable time setting up GA dashboards before.
- I'm not keen on large companies hoovering up data.
- I don't like cookies. I mean, I love cookies, but not on websites. Dropping GA let me drop the cookies, which let me drop the cookie banner, and I'd rather not inflict one of those on anybody.
So my analytics of choice landed on Umami. Why, you may ask? Because it's the best alternative in the world? Well, for my use case it was, but it also has a Japanese name that sits well with a brand called Edokko, and that's a bigger part of the equation than I'd like to admit.
None of that is an argument about page weight, and the page is lighter anyway. That keeps happening, which I think is the actual point of this pillar. Self‑hosting the fonts because they're licensed removes a connection to somebody else's CDN. Refusing an analytics vendor removes another one, along with its cookie, the banner the cookie needs, and the JavaScript the banner needs. Deciding on principle and deciding for speed kept arriving at the same answer, which is either luck or a sign that the two are less separate than a performance checklist makes them look.
One thing here I did decide with the visitor in mind. The analytics are served from this domain rather than from a vendor's, and a script coming off the site it measures doesn't look like a tracker to a blocker, so the numbers I get are the numbers rather than the numbers minus everyone running uBlock.
The remainder is unremarkable. Type scales with clamp() from a phone up to the 1440px width I
designed at, so nothing jumps at a breakpoint to catch up, and pages are built ahead of time so a
visitor gets HTML.
Measured on the live site on 9 August 2026, over a throttled mobile connection: 0.91s and 0.0625, against thresholds of 2.5 seconds and 0.1. Those are the worst of the 4 routes I measured, not the best, because quoting the best of anything is how you end up believing it.
Pillar 2 — UX: navigation and accessibility
Accessibility is where I found out the site had been lying to me.
I'd built a focus ring on purpose, a two‑color halo tuned so that someone navigating by keyboard can see where they are on the light theme and on the dark one. I checked it by inspecting elements, and every interactive thing on the page reported having a focus indicator, so I stopped thinking about it.
Five of them had never once shown it: the article cards, the author card, the table‑of‑contents
links, the share buttons. All of those sit inside a container with overflow: hidden, which clips
whatever a child element paints outside its own box, and an outline is painted outside the box. The
ring was being drawn and thrown away in the same frame. So had the browser's own default ring, for
that matter, since long before I wrote any CSS of my own.
What stopped me being shocked was noticing which five they were. All of them are components I hand‑rolled for this site, while the switch in the header had it right, and that one comes out of Noren, the design system I've been building on the side. I'd have found that argument smug coming from anyone else. I can't dispute it either, having run the experiment on myself by accident.
The navigation half of this pillar is quieter and I'd defend it just as hard. There are three links in the site header, which took some restraint. An article carries a table of contents that tracks where you are as you scroll, and a progress bar showing how much is left, which matters more than it sounds on a two‑thousand‑word piece. Switching language doesn't reload the page. Every animation here stops if the visitor's system asks for reduced motion, including the one I like most.
None of that was a separate accessibility job. It's the same list read twice. The table of contents is real links with real text, so somebody using a screen reader can jump between sections instead of listening to the whole thing, and everybody else gets to find their place after wandering off to make coffee. Honouring reduced motion spares people who get sick from movement, and it spares everybody else's battery. Improving one improves the other, and I've stopped keeping two lists.
The part worth passing on is about method rather than CSS. A computed style tells you what the browser calculated, which is a different question from what it put on the screen, and I'd been checking the first while believing I had checked the second. No automated tool caught it either, since they read computed styles too. There's an axe sweep running now over every route in both themes on every commit, at WCAG 2.1 AA plus best practices, and it fails the build instead of filing a report I'd learn to scroll past. It still wouldn't have caught this particular bug, which is why I diff screenshots now as well.
Pillar 3 — Content that's actually structured
The Gazette used to be for something else.
When I first wrote this article, this was still an agency site, and the blog did what agency blogs do: general advice, second person, here is how you should approach the thing. That's a legitimate job for a blog to have. It stopped being the job I wanted this one doing.
The brief now is narrower, and it's mostly about specificity. What I did on one particular thing, what it cost me, where I had it wrong. The article you're reading is the first written that way, and it's a rewrite of one of those two, which is either tidy or a bit too neat depending on your mood.
That's a structural decision as much as an editorial one. A search engine working out whether a page deserves to rank is partly working out whether it says anything the other results don't, and "the five pillars of SXO" is available everywhere, while what those five pillars cost on one specific site is available here. It's the only durable advantage a small site has, so I'd rather use it than compete on volume with people who have more of it.
The unglamorous half is real too. One h1 per page, headings that never skip a level, and every
article stored per language as its own file rather than one file with translations bolted onto the
side. Each article also describes itself in a form a machine can read without guessing: the
headline, who wrote it, when, and which language the words are actually in. That last one does more
work than it looks like it does. Where an English URL is still serving French, because I haven't
finished translating it, the page withholds that description entirely rather than filling it in with
a language it isn't written in.
Pillar 4 — Understanding search intent
Search intent is the question sitting behind the words somebody typed. Two people can search the same thing and want different pages: one wants a definition, the other wants to know whether it's worth their afternoon. Ranking for the query and then disappointing whoever arrives is worse than not ranking, because they leave and the leaving is measured.
I wrote this piece for the second kind of reader. "What is SXO" is answered in a hundred places by people with more authority on the subject than me, so I didn't write that. What almost nobody writes is what the five pillars cost somebody who actually did them, which is the thing I'd have wanted back when I was the one losing arguments about buttons. It's also why this site exists at all. I'm writing for people who want to watch something get built, not for people who want a definition, and that decides the shape of every article before a word of it exists.
On a bilingual site a second intent stacks on top of the first, which is language, and the quickest way to fail somebody is to hand them the right subject in the wrong one.
Every article has its own slug in each language, rather than one slug with a language flag bolted on. Every page declares its alternates, and names which version to serve a visitor the site has no better match for. Canonicals are explicit, the sitemap lists each URL with its language siblings attached, and there's an RSS feed for people who would rather not go through anybody's algorithm at all.
And where an English URL currently serves French text, because I haven't translated that one yet, the page declares the real language of the text and asks not to be indexed. It isn't dressed up as a translation. Leaving it in the index would bring more traffic, and it isn't something I considered doing.
Pillar 5 — Watching what happens next
This pillar gets called measurement, which undersells it. What it actually means is a loop: build the thing, look at what happened, learn something you didn't know while you were building it, then go back and do it better. The looking is the step that gets skipped, mine included, because building is more fun and nobody makes you check.
What I want to know about this site is whether anybody comes back.
That's a narrow question and it has a number attached to it, which Umami calls retention. Pageviews tell me a post got shared somewhere. Retention tells me whether the person who read it thought it was worth returning for, and since the point of building in public is to end up with people who follow the work rather than people who landed once from a search result, that's the number I open first.
The rest of what I look at is short. Pageviews split by language, which tells me whether writing in English first was the right call. Where readers arrive from, so I know which platform is worth the effort of posting to. And four events covering the things a reader can actually do here: share an article, follow a link out of one, click through to me somewhere else, or switch language. That's the entire list, because I didn't want to instrument anything I didn't have a question for.
All of it self‑hosted and cookieless, which means there's no banner on this site, not because I found a way around the banner but because there's nothing to put in one.
The measurement that changed something, though, wasn't any of those. It was processor time.
This site has a film grain over everything by default, a canvas that repaints continuously. I'd been suspicious of it for a while, and when I finally audited performance I went in expecting to convict it and switch it off by default.
It does cost something. It also turned out not to be the expensive one. A scrolling marquee band, the sort of ornament you stop seeing after a week, was running its animation loop every single frame on three of this site's page types, including when it was scrolled completely off screen. Nothing had ever told it to stop, because it had never occurred to me that it should. It cost more than the grain did, for something nobody was looking at.
Neither showed up in any of the usual metrics. Both are far too small to register as long tasks, and neither moves largest contentful paint or layout shift at all. The two things quietly costing the most were invisible to precisely the tools meant to find them.
Pausing the marquee when it's off screen took four lines and cut idle processor use on an article page by about three quarters. The grain I kept. Its cost, once I could actually see it, was small enough to ignore. I kept it because it's part of the brand. Edokko isn't meant to look clean. The grain is there for the same reason the article thumbnails carry a texture, a bit of Kintsugi thinking, where you don't sand the repair out of the object, you let it show. Which is a strange thing to say about a CSS decision until you notice it's also what this whole article is.
Conclusion
Five pillars is a decent enough map. Having walked them on one site, what I'd add is that three of them came down to discipline and two of them were where anything interesting happened.
Speed, intent and structure you already know how to do, and the work is keeping at them when nobody is watching. It helps to accept that a fair share of the result arrives from decisions you made for unrelated reasons, which is either humbling or a relief depending on the day.
Accessibility and measurement behaved differently, because both of them punish you for trusting your own tools. My focus ring was fine according to the browser and invisible on the screen. My performance problem turned out to be the component standing next to the one I suspected.
Which leaves me with something that isn't really about SXO at all. "I checked" and "I looked" are two different verbs, and I'd been using the first one while telling myself I'd done the second.
