On-Page SEO That Doesn't Ruin UX: Headings, Links, and Content

The framing of "SEO vs. UX" is mostly wrong, and it leads to bad decisions on both sides. Teams that optimize for search first often end up with keyword-stuffed headings, awkward exact-match anchor text, and a paragraph of throat-clearing "SEO content" bolted onto the bottom of a page that nobody reads. Teams that optimize for UX first sometimes strip out the structure — clear headings, descriptive links, a logical outline — that both users and search engines rely on to understand a page.

The pages that actually perform well do neither. They're built around one idea: structure that helps a person scanning the page is almost always the same structure that helps a crawler parsing it. Where that's not true, the exceptions are narrow enough to name.

Headings: one job, and it isn't keyword placement

An H1 states what the page is about, once, clearly. H2s and H3s below it should form an outline you could read as a table of contents and understand the page's argument without reading a word of body copy. That's the test we use: strip everything but the headings — does it make sense?

A few specifics that matter more than people expect:

• One H1 per page, always. Multiple H1s don't directly penalize you, but they dilute the single clearest signal you have about what the page is primarily about.
• Don't skip levels. H1 to H4 with no H2/H3 between them breaks the outline for screen reader users navigating by heading, which is a real accessibility cost, not a theoretical one.
• Write headings for a scanning human first. "Our Approach to Enterprise Software Development Services" is worse than "How we work" — the keyword-stuffed version doesn't actually rank better in most cases, and it reads like a form letter.
• Include key terms where they fit naturally, not because a checklist demands it. A heading like "Pricing" that could accurately be "Pricing and Plans" because that's genuinely what the section covers is a fine, honest improvement. Forcing "Affordable Enterprise Software Pricing Plans 2024" into the same spot is the pattern that makes both users and, increasingly, search engines distrust a page.

If your CMS or component library generates headings automatically (a page builder, a blog template), audit the default output once — we've seen templates that silently emit H3s styled to look like H2s, or skip a level for pages with no subtitle. Fix it at the template level so every page inherits the correct structure by default, instead of relying on every content editor to catch it.

Links: the anchor text test

Internal links do two jobs at once: they help a person find related content, and they tell a crawler what the linked page is about, based on the words used to link to it. Both jobs are served by the same practice — descriptive anchor text that names what the destination actually is.

"Click here" and "read more" fail both tests. A person scanning the page gets no information about what they'd be clicking into; a crawler gets nothing to associate with the destination URL beyond "click here," which is worthless as a signal. "See our guide to Core Web Vitals" does both jobs in the same six words.

Where to link, practically:

• To genuinely related content — a blog post that expands on a point, a service page that's directly relevant, a definition for a term a reader might not know.
• From high-traffic pages to pages that need more internal authority (a new service page benefits enormously from a link on the homepage or a popular blog post).
• Sparingly enough that no link block reads like a directory. Three to six contextual links in a 1,000-word article is normal; twenty is a pattern search engines have gotten good at recognizing as manipulation, and it's a worse reading experience regardless.

External links to genuinely good sources — documentation, research, a tool you're recommending — build reader trust and cost you nothing in rankings; the old fear of "link juice leaking out" hasn't reflected how search engines actually work in a long time. Open them in a new tab only when leaving would interrupt something (a form in progress, a multi-step flow) — for a blog post, let the reader's own tab-management habits decide.

Content: answer the query, then stop padding

Thin or duplicated content is a real problem; padded content is a different, more common one. A page that answers the user's question in 400 words and then adds 600 more words of restatement to "look more thorough" usually performs worse, not better — readers bounce, and increasingly, search systems are tuned to recognize and discount filler.

Two practical checks before publishing:

1. Does this page answer what someone searching that term actually wants? Not "does it contain the keyword" — does it resolve the intent. A search for "Next.js caching" wants an explanation with examples, not a marketing pitch that mentions caching twice.
2. Is there a shorter version of this page that says the same thing? If yes, that's the version to publish. Length isn't a ranking factor on its own — completeness is, and completeness and length are correlated only up to the point where the question is actually answered.

One consolidated, thorough page beats three thin pages targeting slightly different keyword variants almost every time — the split content competes with itself for the same intent and dilutes the signal each individual page could have built on its own.

Where SEO and UX genuinely conflict — and the tie-breaker

They mostly don't. The handful of cases where they do:

The tie-breaker we use: if a change would make an actual visitor's experience worse in order to add a search signal, don't make it. Modern search ranking increasingly correlates with user signals anyway — pages people bounce from because they're padded or awkward tend not to hold rankings even if they briefly rank on-page factors alone.

The version of this that's easy to get wrong

The most common failure mode we see in client audits isn't malicious keyword stuffing — it's a well-meaning content template that adds an "SEO paragraph" to the bottom of every page, written to satisfy a checklist rather than a reader. It's usually the first thing worth cutting in an audit, and cutting it rarely hurts rankings, because that paragraph was never doing the work anyone assumed it was doing.

We build this thinking into every site from the template level — heading hierarchy, link patterns, and content structure baked into the components, not left to each editor to remember — as part of performance and SEO work on every build. If you're auditing an existing site and want a second opinion on what's actually helping vs. padding, get in touch.