9 web design best practices for pro sites (that don’t break)

After many years designing and building websites, there’s a set of tricks I use on every single project. They’re nothing earth-shattering, but they’re the web design best practices that make the difference between a site that “works” and a site that looks professional and doesn’t cause problems. Here they are with CSS examples so you can apply them today, whether you use Astro, WordPress with Bricks or anything else.

1. Stop horizontal scroll at the section level

Few things give away a poorly built website like that horizontal scroll on mobile: one element sticks out a little and the whole page wobbles from side to side. The quick fix is to clip whatever overflows in each section.

section {
  overflow-x: clip;
}

A pro tip: use overflow-x: clip instead of the classic overflow: hidden. Visually it does the same thing, but hidden turns the section into a scroll container and breaks position: sticky on any element inside it. clip crops without that side effect.

That said, this is a safety net, not an excuse: if something overflows, ideally you should find the culprit (I’ll show you how in tip 5).

2. The H1 doesn’t have to be the biggest text

A lot of people think the H1 always has to be the biggest text on the page. It doesn’t. The H1 is a semantic matter: it tells Google and screen readers what the page’s main topic is. Its visual size is a design decision.

If you look at benchmark sites like Webflow’s, you’ll see that the H1 is often a more restrained piece of text, and another element takes the visual spotlight. You can do the same:

<h1 class="hero-eyebrow">Web design for businesses in Barcelona</h1>
<p class="hero-display">Websites that sell, not just look good.</p>

That way you keep a keyword-rich H1 for SEO and a display headline built to make an impact. Semantic hierarchy and visual hierarchy don’t have to match.

3. Don’t break sentences with <br>

It’s very tempting to drop in a <br> so the headline breaks exactly where it looks nice on your screen. The problem is that on another screen (or at another zoom level) that break lands somewhere absurd and leaves you with an orphaned word on the line below.

The right way is to control the width and let the browser distribute the lines:

.hero-title {
  max-inline-size: 18ch;   /* max width in characters */
  text-wrap: balance;      /* spreads the text into balanced lines */
}

p {
  max-inline-size: 65ch;   /* comfortable reading width */
  text-wrap: pretty;       /* avoids orphaned words at the end */
}

balance is ideal for headlines and pretty for paragraphs. The result: nicely broken headlines on any screen, without a single <br>.

4. Fluid headings with clamp()

Instead of setting heading sizes with media queries for every breakpoint, use clamp() so the text scales fluidly between a minimum and a maximum:

.hero-title {
  font-size: clamp(2.5rem, 1rem + 7vw, 7.5rem);
}

Read it like this: never smaller than 2.5rem, never larger than 7.5rem, and in between it grows with the screen width. Two important details:

• The middle value mixes rem and vw, not plain vw. A size set only in vw doesn’t respond to browser zoom, and that’s an accessibility problem for anyone who needs to enlarge the text.
• Minimum and maximum in rem, so they respect the font size the user has set.

If you don’t want to calculate the values by hand, tools like utopia.fyi generate the whole scale for you.

5. Master the browser inspector

The browser inspector is probably the most underrated tool in web design. With it you can edit CSS live, test states (:hover, :focus), simulate devices or see exactly which rule is overriding another in the Computed tab.

A trick I use a lot: if you’ve got horizontal scroll and don’t know which element is causing it, paste this into the console:

document.querySelectorAll('*').forEach((el) => {
  if (el.getBoundingClientRect().right > document.documentElement.clientWidth) {
    console.log(el);
  }
});

It lists every element that sticks out on the right. You’ll find the culprit in seconds instead of deleting sections blindly. (If you like using the console this way, my article on typography in web design has another script for testing Google Fonts on any website.)

6. Give the H1 and the description their own class

The key elements of a section, like the main headline and its description, deserve their own class, not a combination of generic utilities like text-16 font-bold leading-tight. Those standard sizes are almost never exactly what the design needs.

.hero-title {
  font-size: clamp(2.5rem, 1rem + 7vw, 7.5rem);
  line-height: 1.05;
  letter-spacing: -0.02em;
  max-inline-size: 18ch;
  text-wrap: balance;
}

.hero-description {
  font-size: clamp(1.125rem, 1rem + 0.5vw, 1.375rem);
  line-height: 1.5;
  max-inline-size: 48ch;
  color: var(--color-muted);
}

With a dedicated class you can tune line height, tracking and width to exactly what you need, and if you want to change it tomorrow, you change it in one place. It works the same way in Bricks Builder: create a global class for each one and reuse it across every page.

7. Go easy on color, and save the accent for what matters

Users don’t read websites: they scan them. And the eye goes straight to whatever has color. If you paint everything in color, nothing stands out.

My advice is to build the site on a base of neutrals and save the accent color for what you really want people to see: the contact button, the price, the key figure.

:root {
  --color-bg: #fafafa;
  --color-text: #171717;
  --color-muted: #525252;
  --color-accent: #3b54e4;
}

.btn-primary {
  background: var(--color-accent);
  color: #fff;
}

If the accent shows up in three places on the page, those three places are what the user is going to see. Use it like a highlighter, not a paintbrush.

8. You don’t need more than 4 font weights

Every font weight is a file the browser has to download. Loading everything from 100 to 900 “just in case” is dead weight that slows your site down.

In practice, four weights are plenty: 300, 400, 500 and 600. Light for details, regular for body text, medium for emphasis and semibold for headings.

@font-face {
  font-family: "MyFont";
  src: url("/fonts/myfont-variable.woff2") format("woff2");
  font-weight: 300 600;   /* only the range you need */
  font-display: swap;
}

If the font comes in a variable version, even better: a single file covers the whole range. And host it on your own domain instead of pulling it from the Google Fonts CDN: you gain speed and save yourself privacy headaches.

9. What your blog needs to rank

A well-written blog won’t rank if it’s missing the basic technical pieces. Before you publish, check that every post has:

• A single H1 with the keyword, and a clean hierarchy of H2s and H3s.
• A title and meta description of its own, unique to each article.
• A short, descriptive slug (/web-design-best-practices, not /post-123).
• A canonical link to avoid duplicate content.
• Optimized images (WebP or AVIF) with descriptive alt text.
• Internal links to other related articles, with descriptive anchor text (never “click here”).
• An up-to-date sitemap, linked from robots.txt.
• Open Graph tags so it looks good when shared on social media.
• Publish and update dates, clearly visible.
• Good load speed: none of the above is worth much if the page takes ages to open.

Conclusion

None of these tricks is complicated, but together they’re what separates a website built “by eye” from a professional one: no horizontal scroll, headings that adapt to any screen, color that guides the eye and a technical foundation Google understands. Use them as a checklist on your next project and you’ll notice the difference, and so will your clients.