HTML for Business Websites: What Actually Matters in 2026

Most business websites don’t have an HTML problem you can see. They have one you can measure: slow pages, broken accessibility, and markup that search engines and screen readers both struggle to parse. If you’re maintaining a site built five or ten years ago, the issues are usually in the same handful of places.

This isn’t about chasing new syntax. HTML5 has been stable for years. What changed is how much the browser, Google, and assistive tech expect from your markup. Here’s what I look at first when I audit a site, and the fixes that actually move the needle.

Start with semantic structure, not divs

The single most common problem I see is a page built entirely from <div> tags with class names like header-wrapper and nav-container. It renders fine. It also tells a screen reader nothing about what’s on the page.

HTML has had semantic elements for over a decade. Use them:

<header>
 <nav aria-label="Main">
 <ul>
 <li><a href="/services/">Services</a></li>
 <li><a href="/about/">About</a></li>
 </ul>
 </nav>
</header>

<main>
 <article>
 <h1>What we do</h1>
 <p>...</p>
 </article>
</main>

<footer>
 <p>&copy; 2026 Your Company</p>
</footer>

This matters for two reasons. Screen readers let users jump between landmarks, so a blind visitor can skip straight to <main> instead of tabbing through your nav every time. And search engines use the same structure to figure out which part of the page is the actual content versus boilerplate.

One h1 per page, and make it count

I still find pages with four <h1> tags because someone styled headings by size instead of by meaning. Heading levels describe hierarchy, not font size. Fix the outline first, then style with CSS. Your <h1> should describe the page, not repeat your logo text.

Images: the biggest performance win sitting right there

Images are usually the heaviest thing on a business site, and most of them are shipped wrong. Three fixes cover most of it.

• Use modern formats. WebP and AVIF are supported everywhere that matters in 2026. AVIF typically beats WebP on file size, WebP is safer for older tooling. Serve both with <picture> if you want to be thorough.
• Always set width and height. This reserves space so the page doesn’t jump around as images load. Layout shift is a real ranking and usability factor.
• Lazy-load anything below the fold. Native loading is one attribute.

<img
 src="https://i0.wp.com/www.kennykey.com/images/team-office.webp"
 alt="Team reviewing a website layout on a monitor"
 width="1200"
 height="800"
 loading="lazy"
 decoding="async">

That alt attribute is not decoration. If the image conveys information, describe it. If it’s purely decorative, use alt="" so screen readers skip it. Don’t stuff keywords in there. It reads as spam to both users and crawlers.

Stop using images for text

If your phone number or a headline is baked into a PNG, it’s invisible to search, unselectable, and blurry on high-DPI screens. Use real text. There’s no upside to the image version.

Forms that don’t fight the user

Contact forms are where leads either convert or bounce. Bad HTML here costs you money directly. Every input needs a real label tied to it:

<form action="/submit" method="post">
 <label for="email">Email address</label>
 <input
 type="email"
 id="email"
 name="email"
 autocomplete="email"
 required>

 <label for="message">How can we help?</label>
 <textarea
 id="message"
 name="message"
 rows="5"></textarea>

 <button type="submit">Send</button>
</form>

The type="email" gives mobile users the right keyboard. autocomplete lets browsers fill it in. The label is clickable, which helps everyone and is mandatory for accessibility. Placeholder text is not a label. It disappears the moment someone starts typing, and it fails contrast requirements in most designs.

Accessibility is not a separate project

Semantic HTML, labeled forms, and described images already handle most of what WCAG asks for. The remaining common gaps are small:

• Color contrast. Body text needs a 4.5:1 ratio against its background. Light gray text on white looks clean in a mockup and fails in reality.
• Focus states. Never remove the outline on focusable elements without replacing it. Keyboard users need to see where they are.
• Language attribute. <html lang="en"> tells screen readers how to pronounce your content. One attribute, easy to forget.
• Buttons vs links. If it goes somewhere, use <a>. If it does something, use <button>. Swapping them breaks keyboard behavior.

Beyond being the right thing to do, this increasingly has legal weight. Accessibility lawsuits against small businesses have kept climbing, and most of the failures are things you can fix in an afternoon.

Metadata still does the heavy lifting for search

Your <head> is where search engines get their first impression. The essentials haven’t changed much:

<head>
 <meta charset="utf-8">
 <meta name="viewport" content="width=device-width, initial-scale=1">
 <title>Plumbing Services in Commack, NY | Your Company</title>
 <meta name="description" content="Licensed plumbers serving Commack and the surrounding area. Same-day service, upfront pricing.">
 <link rel="canonical" href="https://example.com/plumbing-commack/">
</head>

The viewport tag is what makes the page usable on phones. The canonical tag tells Google which URL is the real one when you have duplicates, which happens constantly with tracking parameters and print versions. The title and description are still what shows in search results, so write them for a human deciding whether to click.

Structured data for local businesses

If you serve a specific area, add LocalBusiness schema. It’s JSON-LD in a script tag and helps search engines connect your site to a place and hours:

<script type="application/ld+json">
{
 "@context": "https://schema.org",
 "@type": "LocalBusiness",
 "name": "Your Company",
 "telephone": "+1-631-555-0100",
 "address": {
 "@type": "PostalAddress",
 "streetAddress": "123 Main St",
 "addressLocality": "Commack",
 "addressRegion": "NY",
 "postalCode": "11725"
 },
 "url": "https://example.com"
}
</script>

Don’t fake reviews or ratings in this block. Google will catch it, and it’s a fast way to lose rich results entirely.

What I’d actually do first

If you’re staring at an old site and don’t know where to start, work in this order:

• Run your homepage through PageSpeed Insights. Fix whatever it flags as the largest contentful paint.
• Check heading structure on your top five pages. One <h1>, logical order below it.
• Compress and convert every image over 200KB to WebP.
• Tab through your contact form with the keyboard only. If you can’t see where focus is, fix that.
• Add the viewport meta tag if it’s missing. You’d be surprised how often it is.

None of this is glamorous. It’s the difference between a site that quietly works and one that leaks visitors without anyone noticing. When the fixes run deeper than markup, like a platform that’s fighting you at every turn, it’s usually worth talking through a rebuild rather than patching a structure that was never right. That’s the kind of work I do through custom web development, and it starts with an honest look at what you already have.

FAQ

Do I need to rewrite my whole site to fix these issues?

No. Most of the wins here are targeted edits: image formats, heading structure, form labels, a viewport tag. A full rewrite is only worth it when the underlying structure makes every fix a fight.

Does semantic HTML actually affect Google rankings?

It’s not a direct ranking factor, but it feeds the signals that are: page speed, mobile usability, and how easily crawlers understand your content. The accessibility benefits alone justify it.

How often should I audit my site’s HTML?

Once a year for a full pass, and any time you ship a redesign or add a major feature. Small regressions pile up fast, especially when multiple people edit the same pages.