A client once sent over a homepage where the entire welcome message was baked right into a banner image. The headline, the subhead, even the button, all flattened into one JPEG. On a desktop monitor it looked fine, but on a phone the text shrank down until it was barely readable, and worse, it didn’t show up anywhere in a Google search for the business’s own name.
That’s usually how these things go. A mistake gets made for a perfectly reasonable reason in the moment, it looks fine at a glance, and it quietly sits there working against the site until someone with a trained eye points it out. Here are six of the most common ones I run into, why they tend to happen in the first place, and how I’d go about fixing each one.
Text baked into an image
This one almost always comes from a handoff problem. A client has a flyer, a PDF, or a graphic they used on social, and the path of least resistance is to drop that image straight onto the website. It’s quick, easy and feels like “mission accomplished.”
5 Epic Font Pairings You Can’t Go Wrong With
Tired of searching for fonts? With my 10+ years of design experience, I’ve put together the best font pairings for you to use, where to find them, and what industry they’re best for.
Get the Free Guide
The trouble is that text baked into an image can’t scale independently from the image itself. It might look fine on a large screen, but shrink that image down for mobile and the text shrinks right along with it, often down to a size nobody can actually read. On top of that, Google has no way to crawl text sitting inside a JPEG or PNG, so if your headline or call to action lives inside an image file, it’s invisible to search engines entirely.
The fix is to rebuild that message as real text layered over the image rather than flattened into it. In a page builder like GenerateBlocks, that usually means setting the image as a background on a container and placing an actual headline and text element inside it. While you’re at it, check the contrast between the text and the image behind it. You want at least a 4.5:1 ratio for body text so it stays legible no matter the screen size.
Every button is the same color
Once a brand color gets chosen, there’s a natural pull toward using it everywhere for the sake of consistency. A blue button feels “on brand,” so the instinct is to make every button on the site that same blue.
But buttons aren’t just a branding decision, they’re a hierarchy decision too. A “Schedule a Call” button and a “Get to Know Us” button are asking for two very different levels of commitment, and if they look identical, you’ve removed the visual cue that tells a visitor which action actually matters most. When everything is emphasized equally, it’s easy to get decision fatigue.
A simple fix here is setting up two button styles instead of one. A primary style, usually solid and in your main brand color, reserved for the one action you most want someone to take. And a secondary style, often an outline or a more muted tone, for lower-stakes actions like “Get to Know Us.” Most builders make this easy to set up as global styles, so it just becomes a matter of applying them with intention rather than defaulting to whatever button style is closest at hand.
Body copy runs full width
This one tends to slip through because it looks perfectly fine on a designer’s wide monitor. The text fills out the container, the layout feels balanced, and it’s easy to move on without actually testing how it reads at that width.
Readability research has pointed to the same number for a long time now, somewhere around 60 to 80 characters per line is the sweet spot for comfortable reading. Once a line runs longer than that, the eye has to work harder to find the start of the next line, and that extra effort adds up fast over a long page.
The fix is to constrain your text containers, and the easiest way to do that is with a max-width set in character units (around 65ch) or in pixels (I like 800px).
The nice thing about the ch unit is that it scales with the font itself, so it holds up well across different font sizes and devices. If you’re working in GenerateBlocks, you can set this same value directly in a container or element’s max-width field using 65ch or 800px.
Mixing icon libraries
It’s common to reach for certain icons you’re looking to match your copy from different icon libraries. One icon comes from Font Awesome, the next one comes from Phosphor, and you think nothing of it.
The problem is that different icon libraries have different stroke weights, corner radii, and overall styles. Put a thin outlined icon next to a bold filled one and the page starts to look inconsistent.
The fix is choosing one icon library before development even starts, and sticking with it for the life of the site. If you’re auditing a site that already has this problem, take a quick inventory of every icon in use, group them by source, and standardize on whichever library has the broadest set you actually need. Phosphor, Lucide, and Material Design are all solid, comprehensive options.
Drop shadows on everything
A drop shadow is a quick way to make a flat element feel like it has some depth to it, so once it gets applied to one card or button and it looks good, it’s tempting to apply that same effect everywhere for consistency’s sake.
Used sparingly, a shadow draws the eye and signals that something is elevated above the page. Used on every card, button, and image, that suddenly means nothing, and the whole design starts to look overdone and dated.
A good habit here is auditing every element with a shadow and asking whether it’s actually serving a purpose, like separating a card from the background behind it, or whether better spacing and contrast would accomplish the same thing without the extra weight. As a general rule, I save shadows for genuinely elevated UI like modals and select cards, and let everything else rely on borders, background contrast, or whitespace instead.
Hover effects on non-interactive elements
Hover animations are an easy way to make a page feel a little more “elevated”, so they often get sprinkled across cards, images, and sections during a final polish pass near the end of a build.
The problem is that a lift, a scale, or a color shift on hover is a learned signal, one we’ve all picked up over years of using the web, that tells us something is clickable. So when a card animates on hover but doesn’t actually link anywhere, a visitor clicks it expecting something to happen, nothing does, and that instantly causes distrust.
Before adding any hover state, it’s worth confirming the element is actually wrapped in a link or button first. If it’s not truly interactive, it’s better left alone. As a rule, hover effects should only ever live on something the URL bar will confirm is actually clickable.
How many did your site have?
Most sites have at least one or two of these hiding in plain sight. None of them require a full redesign to fix, most are a quick CSS tweak or a small content edit away. The harder part isn’t the fix itself, it’s training your eye to catch these things in the first place.
Once you start looking for them, you’ll start noticing them everywhere, on your own site and everyone else’s too.
