Bad Habits in Web Development We Should Avoid

Imagine you've just launched a website. On your 27-inch monitor it looks great. Then a friend opens it on their phone and sends you a screenshot: the menu overflows, the buttons are tiny, and half the page needs sideways scrolling.

Nothing in the code is "wrong" in a way that throws an error. The site just carries a few quiet habits that make it worse for real people, and worse to maintain. They're easy to pick up, because each one saves a little time today and charges for it later.

Here are five of the most common ones. For each, we'll look at how it bites and what to do instead. We'll start with the one from that screenshot.

1. Not Thinking About Mobile from the Start

Most users reach the web from a phone. Treating mobile as an afterthought, something you squeeze the desktop layout into at the end, is a critical mistake. Fixing it late means undoing decisions the whole page was built on.

A mobile-first approach flips the order: make sure the site works and looks good on small screens first, then scale up to larger ones.

What to do:

• Prototype the mobile layout first and check the experience across different screen sizes.
• Write base styles for small screens and use min-width media queries to enhance for larger ones.

/* Base: small screens */
.card-list {
  display: grid;
  gap: 1rem;
  grid-template-columns: 1fr;
}

/* Larger screens: enhance */
@media (min-width: 768px) {
  .card-list {
    grid-template-columns: repeat(3, 1fr);
  }
}

Once the layout holds up on every screen, the next thing a visitor notices is whether the pages feel like they belong together.

2. Being Inconsistent

Picture a visitor clicking through your site. On the home page, the active link is blue. On the pricing page, it's green. On the blog, it's underlined and red. Nothing is broken, but the visitor starts to wonder whether they're still on the same site.

Inconsistent design, links and styles confuse users and make a product feel unprofessional.

What to do:

• Define and follow a style guide covering colors, typography, buttons and links.
• Use a design system (Material Design, Bootstrap, or your own) to keep visual and functional coherence.
• Centralize design values as tokens instead of repeating them:

:root {
  --color-link: #0b5fff;
  --color-link-active: #0a3fb3;
}

a { color: var(--color-link); }
a:active, a[aria-current="page"] { color: var(--color-link-active); }

Change the token once, and every page follows. Which is exactly the opposite of what happens with the next habit.

3. Hardcoding URLs

Say the site has a hundred pages, each linking to https://www.mysite.com/.... Then the domain changes. Or someone needs a staging copy to test a release. Suddenly every link points to the wrong place, and the fix is a search-and-replace across the whole project.

Fixed URLs in the source code make a site harder to maintain and scale. They break whenever the domain changes or you work across several environments (development, staging, production).

What to do:

• Prefer relative paths over absolute ones for internal links and assets.
• Use environment variables to handle environment-specific URLs, like an API base URL.

// Bad
fetch("https://api.mysite.com/users");

// Better
fetch(`${process.env.API_BASE_URL}/users`);

<!-- Bad -->
<a href="https://www.mysite.com/about">About</a>

<!-- Better -->
<a href="/about">About</a>

So far we've looked at habits that hurt maintainers. The next one hurts the people who can't see the page at all.

4. Leaving Out the alt Attribute on Images

Think about someone using a screen reader landing on your product page. Where there should be a photo of the product, the reader says only "image", or worse, reads out a file name like IMG_4821.jpg. The same thing happens to everyone when an image fails to load on a bad connection.

The alt attribute describes an image to users with visual impairments and to everyone when the image doesn't load. Skipping it makes the page harder to use, and it also hurts SEO.

What to do:

• Give every meaningful image a clear, concise description.
• If an image is purely decorative, use an empty alt="" so assistive technology skips it instead of reading out a file name.

<!-- Informative -->
<img src="chart.png" alt="Bar chart showing mobile traffic growing 40% year over year">

<!-- Decorative -->
<img src="divider.svg" alt="">

Screen readers rely on the structure of the page just as much as on its images, which brings us to the last habit.

5. Using Too Many divs

Open the HTML of a page built this way and you find div inside div inside div, each with a class name that tries to say what the element actually is. For a human it's tedious. For a screen reader or a search engine, it's a page with no landmarks to navigate by.

Reaching for div when a specific semantic element exists makes code harder to read and hurts accessibility and SEO. Screen readers and search engines rely on elements like header, nav, main, section, article and footer to understand the page structure.

What to do:

• Use semantic elements to structure your HTML.
• Keep div for generic grouping, when no better element fits.

<!-- Div soup -->
<div class="header">...</div>
<div class="main">
  <div class="article">...</div>
</div>
<div class="footer">...</div>

<!-- Semantic -->
<header>...</header>
<main>
  <article>...</article>
</main>
<footer>...</footer>

Back to That Screenshot

Go back to the friend's screenshot from the start. Behind the overflowing menu there may be a missing mobile-first layout, inconsistent styles, a hardcoded URL, an image with no description and a page made only of divs. None of them was a big decision, but together they make a site that's harder to use and harder to maintain.

Avoiding these habits improves more than the code: it improves the user experience, accessibility and development efficiency. Building them in from the start makes a site easier to maintain and more robust.

Pick one project, check it against this list, and fix what you find.