DEV Community: ellie miguel

WordPress title and meta description mistakes before launch

ellie miguel — Tue, 07 Apr 2026 13:32:00 +0000

Part of the series: WordPress Pre-Launch Technical Checks

When a WordPress site is about to go live, most teams focus on performance, design and functionality. That makes sense, those are the visible parts. But there are smaller details that tend to slip through, and they matter more than it seems.

One of those is how page titles and meta descriptions are set. It’s not something you notice visually, so it’s easy to leave it for later and forget about it.

The problem is that these elements are among the main signals search engines use to understand and display a page. If they are off at launch, the site can start sending mixed signals from the very beginning.

In practice, it’s worth taking a moment before delivery to check that titles and meta descriptions actually reflect the final structure of the site, not an earlier version of it.

What titles and meta descriptions do

The page title and meta description live in the HTML head, so they’re not visible on the page itself. Still, they play a big role in how that page appears externally.

The title works as the main label, while the meta description gives a short summary. In many cases, this is what ends up showing in search results, shaping the first impression before anyone even clicks.

Why problems appear before launch

During development, these details are often left in a temporary state. Content is still evolving, placeholders are used, or SEO settings are not fully aligned yet.

It’s quite common to reach the end of the project and realize that no one has gone back to review them properly. By then, everything else is ready, so this part gets rushed or skipped.

Common title and meta description issues

Placeholder titles that were never updated

You still see pages going live with titles like “Home” or “Untitled page”. It sounds basic, but it happens more often than expected, especially when multiple people have touched the project.

Repeated titles across different pages

Sometimes templates or SEO settings generate very similar titles everywhere. From a user perspective it might look fine, but for search engines it makes it harder to distinguish what each page is about.

Missing meta descriptions

When there is no defined description, search engines usually generate one automatically. That’s not necessarily wrong, but it removes control over how the page is presented.

Leftover references from staging environments

After migrations, it’s not unusual to find titles or descriptions still referencing development domains or temporary names. It’s a small detail, but it can look messy once the site is public.

A quick review before launch

Before delivering a WordPress site, it helps to run a quick check. Each important page should have a clear title, avoid duplication, and include a description that actually reflects the content.

This doesn’t take long, but it makes sure the site goes live with clean, consistent signals instead of half-finished metadata.

Why this belongs in a pre-launch checklist

These issues rarely break anything visually, which is why they’re easy to ignore. Everything looks fine on the surface, so attention goes elsewhere.

But they directly affect how the site appears in search results and how it’s interpreted. Fixing them later is possible, of course, but it’s one of those things that are better handled before launch.

Where PreFlight fits in

PreFlight focuses on reviewing these kinds of technical details before a site is delivered. It’s basically about catching small issues that are easy to miss when you’re focused on bigger pieces.

If you want to run a quick check before going live, you can start here: https://preflightstandard.com/

And if you want to explore the full set of checks: https://preflightstandard.com/wordpress-technical-checks/

Final thought

Titles and meta descriptions are small details, but they shape how a site is seen before anyone even lands on it.

Taking a few minutes to review them properly before launch can save you from sending the wrong signals right from day one.

When custom WordPress development actually makes sense (and when it doesn’t)

ellie miguel — Tue, 07 Apr 2026 13:27:00 +0000

I’ve reviewed dozens of WordPress projects where the client asked for a “custom rebuild” and the real fix was simpler. Small changes in structure, fewer plugins, or a clearer content strategy often solve 80% of the pain.

One useful rule of thumb

Think of custom development as an investment to solve constraints that are structural, not aesthetic. If the problem is about processes, integrations or scale — the site is in the way of how the business operates — then bespoke work can remove recurring costs and awkward workarounds. If the problem is fuzzy (the messaging, the funnel, or slow edits), a simpler cleanup usually gives faster returns.

When custom development pays off

There are clear signals that off-the-shelf solutions will start leaking time and money. For example: when the website must tie into internal systems, send different leads to different teams, or build pages from data that lives in other tools, a tailored integration prevents a lot of manual glue work. Another example is editing: if every content change requires a developer because templates are brittle, building a controlled editing layer is custom work that pays for itself.

Performance can push you toward custom work too. Not over-optimizing for a minor metric, but when slow pages hurt campaigns or user flows, refactoring critical parts of the site rather than piling on optimizations often ends up being the clearer, longer-lasting fix.

When keeping it simple is the smarter move

If the site is mainly a brochure for services, or the business is still testing offers and audiences, a lightweight, well-structured theme with good content will usually outperform an early-stage bespoke build. I’ve seen startups lock into bespoke features they never used, which meant extra cost and friction when they needed to pivot. Simplicity keeps the site flexible and cheaper to maintain while you learn what actually matters.

Budget matters in a pragmatic way: custom work isn’t just the initial build. Documentation, tests, and maintenance are part of the real cost. A half-funded custom project commonly becomes a fragile patchwork; a solid standard setup often outlasts that fragility.

A short practical check you can run now

Ask four quick questions: does the site need to automate steps tied to internal ops; do editors regularly break layouts when they edit content; is speed affecting real user behavior or campaigns; and would a standard theme plus some configuration cover 70–80% of the needs? If most answers point to process or scale, custom work is justified. If they point to content, structure or budget limits, simplify first and delay bespoke features.

This is a tighter take than the full breakdown I keep on the blog, where I unpack case studies and the exact questions I run in a quick audit. For the longer version with examples and checklist-style diagnostics, see the complete guide on my site: https://elliemiguel.es/diseno-desarrollo-web-wordpress-freelance/

What actually changes when a service website is thoughtfully planned in WordPress

ellie miguel — Thu, 02 Apr 2026 13:26:00 +0000

I've worked with small agencies and solo consultants who blamed WordPress for problems that were never technical. From what I've seen, the real gap is how the site was planned: brochure-style layouts that look nice but don't guide a visitor toward a decision.

The single change that shifts everything

Think of a service site as a tool, not a catalog. When a site is planned with that in mind, three simple things happen: hierarchy becomes clear, each page has a role, and the visitor always has a logical next step. Those are small decisions, but they compound. A homepage that says who you are, who you help, and what a next step looks like reduces vague inquiries and raises the quality of contact requests.

How clearer hierarchy plays out — a short example

Picture two homepages. One shows a carousel of awards, a long hero with a marketing line, and multiple visual blocks that compete for attention. The other leads with a short statement: who the service is for, the main problem solved, and a clear signpost to the relevant service page. The second one doesn’t need to look flashy; it simply saves a visitor mental effort. In practice, that clarity converts weaker curiosity into a useful conversation more often.

Structure, not just design — another quick illustration

Structure means giving every page a job. A service page should explain the scope, set expectations, and show how to move forward; a blog post should answer a specific search intent and link to the next logical step. From what I’ve seen, mixing those roles in one page creates noise: SEO doesn’t work as well, and prospects don’t know how to proceed.

Technical choices that matter without being flashy

Technical stability is underrated. A clean theme setup, sensible editing controls, and dependable hosting make the site maintainable. That isn’t about custom building everything; it’s about choosing where to invest effort so the site can grow without needing constant firefighting. Six months later, the difference is obvious: fewer broken pages, fewer plugin conflicts, and more time spent on content that actually moves the business.

When to patch and when to rebuild

From what I usually recommend, adjust when the technical base is solid and the main issues are messaging or structure; rebuild when the site’s foundation prevents sensible fixes. Signs that rebuilding makes sense include pages that always break with small edits, a template that forces every page to look identical, and persistent performance or maintenance problems that block growth. That pragmatic split helps you stop wasting time on fixes that never get to the root.

If you want the full breakdown — a more detailed checklist and examples from real projects — there’s a complete post on the blog that goes deeper into the decisions and trade-offs: https://elliemiguel.es/disenador-web-wordpress-freelance/

Why your WordPress homepage should respond consistently before launch

ellie miguel — Thu, 02 Apr 2026 13:03:00 +0000

Part of the series: WordPress Pre-Launch Technical Checks

When preparing a WordPress site for launch, most of the attention usually goes to design, performance and content. That makes sense, those are the visible parts. But there are smaller technical details that tend to be left for later, and they can create issues if no one checks them properly.

One of those is how the homepage behaves across different URL variations. It’s not something you notice immediately, but it can lead to inconsistent responses depending on how the site is accessed.

In many projects, the homepage works as expected under one URL, but behaves slightly differently under another. From a user perspective everything might seem fine, but technically it can send mixed signals.

Before delivering a WordPress site, it’s worth taking a moment to confirm that all these variations lead to the same final result.

What “consistent response” actually means

A homepage can usually be accessed through several versions of the same URL. Different protocols, domain variations or small structural differences can all point to it.

In practice, all of them should resolve cleanly to a single canonical version. That way both users and search engines always reach the same page without ambiguity.

Why these inconsistencies appear

During development, WordPress sites often go through multiple environments. Local builds, staging setups, migrations and final deployment all introduce small configuration changes.

It’s easy for redirect rules or domain settings to accumulate along the way. If no one reviews them at the end, the homepage can end up responding differently depending on the entry point.

What usually goes wrong

Protocol differences

Sometimes HTTP and HTTPS don’t behave exactly the same. One version might redirect cleanly, while the other takes a different path or introduces an extra step.

Domain variations

When both www and non-www versions remain active without a clear preference, the homepage can exist under multiple URLs at the same time.

Unnecessary redirect chains

It’s not unusual to see homepages going through several redirects before reaching the final URL. It still works, but it adds complexity that doesn’t really help.

Leftover staging paths

After migrations, some temporary routes or alternative entry points may still be accessible. They’re easy to miss if no one is specifically looking for them.

A quick check before launch

At this stage, a simple review is usually enough. The goal is just to confirm that all variations of the homepage resolve consistently and that there are no duplicate entry points left behind.

It doesn’t take long, but it helps avoid subtle issues that are harder to detect later.

Why this belongs in a pre-launch checklist

These kinds of problems don’t break the site visually, which is why they often go unnoticed. Everything looks fine, so attention goes elsewhere.

However, they do affect how the site is interpreted technically. Cleaning this up before launch keeps the structure clearer from the start.

Where PreFlight fits in

PreFlight focuses on reviewing these technical details before a site is delivered or published. It’s about catching the small things that tend to slip through when the bigger pieces are already done.

If you want to run a quick check before going live, you can start here: https://preflightstandard.com/

And if you want to explore the full set of checks: https://preflightstandard.com/wordpress-technical-checks/

Final thought

The homepage is usually the main entry point, but also one of the most sensitive from a technical perspective.

Making sure it responds consistently across all variations is a small step that helps keep everything aligned from day one.

Open Graph tags missing in WordPress sites before launch

ellie miguel — Tue, 31 Mar 2026 13:27:00 +0000

Part of the series: WordPress Pre-Launch Technical Checks

When reviewing a WordPress site before launch, most teams focus on indexing, performance and security. Those are the obvious areas. But there are smaller details that tend to slip through, and they show up in places you don’t always expect.

One of those is Open Graph metadata. It doesn’t affect how the site works directly, so it’s easy to overlook it during development.

The thing is, this is what controls how your pages look when someone shares a link on platforms like LinkedIn, Slack or WhatsApp. If it’s not configured properly, the site can look broken even if everything else is working fine.

What Open Graph tags actually do

Open Graph tags live in the HTML head and define how a page is presented when it’s shared. They don’t change the page itself, but they shape the preview people see before clicking.

Typically, this includes the title, a short description, an image and the URL that should be associated with the page.

<meta property="og:title" content="Page title">
<meta property="og:description" content="Page description">
<meta property="og:image" content="Preview image">
<meta property="og:url" content="Canonical URL">

These elements might seem minor, but they define that first impression when a link is shared.

Why this matters before launch

Right after a site goes live, it usually gets shared. Clients send it to partners, teams pass it around internally, and sometimes it ends up on social platforms.

If Open Graph tags are missing or incomplete, the preview can look a bit off. Sometimes it pulls a random image, sometimes no image at all, or the text feels cut or out of context.

Nothing is technically broken, but the result doesn’t feel polished.

What tends to go wrong

Missing metadata

Some sites go live without any Open Graph configuration. This can happen when the theme doesn’t handle it and no plugin is managing those fields.

Unclear or missing preview image

When no image is defined, platforms try to guess one. The result is often inconsistent, especially on pages with multiple images.

Default or mismatched titles and descriptions

Sometimes the text used for sharing doesn’t really match the page. It might be inherited from defaults that were never reviewed properly.

Leftover staging references

After migrations, it’s not unusual to find Open Graph fields still pointing to staging domains or temporary assets. It’s a small detail, but easy to miss if you don’t test it.

A quick check before launch

At this stage, a simple review is usually enough. Just make sure the tags are present, the image looks right, and the text reflects the actual content of the page.

It doesn’t take long, but it avoids that awkward moment where a shared link doesn’t look quite right.

Why this belongs in a pre-launch checklist

Because it doesn’t affect functionality, Open Graph is often ignored. Everything works, so it doesn’t feel urgent.

But it directly affects how the site is perceived when it’s shared. Fixing it later is possible, but it’s one of those details that’s easier to get right before launch.

Where PreFlight fits in

PreFlight focuses on reviewing these kinds of details before a site is delivered or published. It’s about catching the small things that don’t break anything, but still matter.

If you want to run a quick check before sharing a site, you can start here: https://preflightstandard.com/

Final thought

Open Graph tags are easy to ignore, but they shape how a site appears in places where first impressions happen quickly.

Taking a few minutes to review them before launch helps keep everything consistent from the start.

Canonical tag mistakes in WordPress sites before launch

ellie miguel — Thu, 26 Mar 2026 14:25:00 +0000

Part of the series: WordPress Pre-Launch Technical Checks

When reviewing a WordPress site before launch, there are a few technical signals that are easy to overlook. One of them is the canonical tag. It’s not something you see on the page, so it often gets less attention than it should.

In practice, this tag plays a key role in how search engines interpret the structure of the site. If it’s not configured properly, different URLs can end up competing with each other without anyone noticing.

Before delivering a project, it’s usually worth checking that canonical behavior is clean and consistent across the site.

What the canonical tag actually does

The canonical tag lives in the HTML head and tells search engines which version of a page should be treated as the main one.

A typical example looks like this:

<link rel="canonical" href="https://example.com/page/" />

It might seem like a small detail, but it helps avoid situations where multiple URLs point to the same content without a clear reference.

This happens more often than expected, especially with parameters, alternate paths or small variations of the same page.

Why these issues appear in WordPress

WordPress generates a wide range of URLs by default. Archives, paginated pages, previews or parameter-based URLs are all part of its normal behavior.

Because of that, canonical signals are usually handled automatically by themes or SEO plugins. And that’s where things can get a bit messy if no one reviews the final setup.

It’s quite easy to assume everything is fine, when in reality the signals don’t fully match the intended structure.

What tends to go wrong

Missing canonical tags

Some pages, especially custom ones, end up without a canonical tag. It’s not always obvious, but it leaves search engines without a clear reference.

Canonical pointing to the wrong place

After migrations, it’s not unusual to find canonicals still pointing to staging domains or older URLs. It’s one of those things that slips through if no one checks it directly.

Multiple canonical tags

Sometimes both the theme and an SEO plugin generate their own canonical tag. When that happens, you can end up with conflicting signals in the page head.

Inconsistent behavior across templates

Different templates can produce slightly different canonical logic. On their own it might not seem critical, but across the site it creates mixed signals.

A quick review before launch

At this stage, a simple check is usually enough. Just confirm that important pages have a canonical tag, that it points to the correct production URL, and that there are no duplicates or leftover references.

It doesn’t take much time, but it helps avoid confusion later on.

Why this belongs in a pre-launch checklist

Canonical issues rarely break anything visually. The site loads, navigation works, everything seems fine.

But under the surface, they affect how search engines interpret the site structure. Fixing them after launch is possible, but it’s cleaner to get it right from the start.

Where PreFlight fits in

PreFlight focuses on reviewing these kinds of technical details before a WordPress site is delivered or published. It’s about catching small inconsistencies before they turn into bigger issues.

If you want to run a quick technical check before launch, you can start here: https://preflightstandard.com/

Final thought

The canonical tag is a small piece of code, but it carries a lot of weight when it comes to how a site is understood.

Taking a moment to review it before launch helps keep everything aligned from day one.

Why the WordPress installer should not be accessible after launch

ellie miguel — Tue, 24 Mar 2026 14:24:00 +0000

Part of the series: WordPress Pre-Launch Technical Checks

When reviewing a WordPress site before delivery, most of the attention usually goes to visible things. Design, content, maybe performance. That’s where the eye goes first.

But there are small technical details that don’t show up unless you look for them. One of those is whether the WordPress installer is still accessible.

It’s not something that comes up often, but when it does, it usually means the deployment process wasn’t fully closed.

Before launching a site, it’s worth checking that everything related to the initial setup is properly finished.

What the WordPress installer actually does

When WordPress is installed for the first time, it runs through a setup process that creates the configuration and prepares the database.

This is done through the installer endpoint, which is only meant to be used once.

After that, it should effectively disappear from normal access.

Why this matters before launch

If the installer is still accessible on a site that is already configured, something didn’t quite close properly during setup.

It doesn’t automatically mean there is a serious issue, but it’s a signal that the environment might not be fully clean.

In a proper delivery, these kinds of leftovers shouldn’t be there.

How this situation usually appears

Partial migrations

During migrations, especially when files and database changes happen in separate steps, things can get out of sync. If the process is interrupted or repeated, the installer logic can behave in unexpected ways.

Development environments pushed to production

Sometimes a development version is copied over without fully cleaning up setup conditions. Most of the time everything works, but small pieces from the initial configuration can remain.

Missing final checks

Launch processes tend to focus on what’s visible. If technical cleanup is not part of the checklist, these small leftovers can easily slip through.

A quick check before launch

At this stage, it’s usually enough to confirm that the installation process cannot be triggered again and that the site behaves as a fully initialized WordPress instance.

It takes very little time, but it helps avoid delivering something that is technically unfinished.

Why this belongs in a repeatable process

When a project goes through multiple environments, small inconsistencies are almost inevitable.

Having a simple, repeatable check for this kind of detail makes it easier to catch them before they reach production.

Where PreFlight fits in

PreFlight focuses on reviewing these technical aspects before a WordPress site is delivered or published. It’s about making sure nothing small but important is left behind.

If you want to run a quick check before handing over a site, you can start here: https://preflightstandard.com/

Final thought

When a site goes live, it should feel finished not only visually, but also technically.

Making sure the installer is no longer accessible is a small detail, but it helps confirm that everything is properly closed.

When a website needs a redesign

ellie miguel — Sun, 22 Mar 2026 13:50:00 +0000

Websites do not stay effective forever.

I notice this quite often when reviewing older projects. What worked a few years ago can slowly stop matching how a business actually operates today.

Sometimes the first signal is visual. The design starts to feel disconnected from the brand, not because it’s “ugly”, but because it no longer reflects the current positioning or level of the business.

In other cases, the problem is more structural. Services evolve, new offers appear, and the website doesn’t adapt well. Pages start to feel forced, or information gets scattered in ways that don’t really make sense anymore.

Mobile usability is another clear indicator. Many older websites technically “work” on phones, but the experience is awkward. Navigation feels clunky, content is harder to read, and small friction points add up quickly.

Performance tends to follow a similar pattern. Over time, small technical decisions accumulate and the site becomes slower or less stable. It’s not always obvious at first, but it affects how users perceive the business.

In some situations, none of these issues seem critical on their own, but together they create a subtle feeling that something is off. That’s usually when a redesign starts to make sense.

I went deeper into these signals and how to detect them in practice here:
https://elliemiguel.es/cuando-redisenar-una-web/

What maintenance a WordPress website needs

ellie miguel — Sat, 21 Mar 2026 14:38:00 +0000

Why WordPress websites need maintenance

A lot of people assume a website is finished once it goes live. In reality, that’s just the starting point. From there, things keep moving, even if nothing looks like it on the surface.

Updates are probably the most obvious part. WordPress, plugins and themes are constantly evolving, and those updates usually include fixes, improvements or security patches. Ignoring them for too long is where problems tend to begin.

Backups are less visible, but just as important. You don’t think about them until something breaks, and then they become the only thing standing between a quick fix and a full rebuild.

Security is another quiet layer that runs in the background. Most websites receive automated attacks regularly, even small ones. A quick review from time to time helps catch issues before they turn into something bigger.

There are also small things that are easy to overlook, like forms. A contact form can stop working without anyone noticing for weeks, which basically means lost opportunities without any warning.

Performance tends to change slowly. Plugins get added, data accumulates, and what used to feel fast starts to drag a bit. It’s not always dramatic, but it affects the overall experience.

None of these things are urgent on their own, but together they define whether a website stays reliable over time or slowly degrades.

I explain what a proper maintenance routine looks like in more detail here: qué mantenimiento necesita una web WordPress

Why many WordPress websites become slow

ellie miguel — Fri, 20 Mar 2026 14:24:00 +0000

Why many WordPress websites become slow

Website speed has a direct impact on both user experience and search visibility. It’s one of those things people notice instantly, even if they don’t always know why.

What I see quite often is that many WordPress websites start fast, but gradually slow down over time. It’s rarely caused by a single issue. In most cases, it’s the result of several small decisions stacking up.

Plugins are usually part of the story. Adding new functionality is easy, but each plugin can introduce extra queries or scripts. At some point, that accumulation starts to show.

Images play a bigger role than it seems. Uploading them without any kind of optimization quickly increases page weight, and that alone can slow things down more than expected.

Hosting is another factor that tends to be underestimated. The same website can behave very differently depending on the server environment, especially when traffic or resource usage grows.

Caching, or the lack of it, also makes a noticeable difference. Without it, the server has to rebuild pages again and again, which adds unnecessary load and delays.

And then there’s the structure itself. Some themes or builders generate quite heavy layouts, and while everything might look fine visually, the underlying code can be doing more work than needed.

In many cases, none of these elements seem critical on their own, but together they explain why a site that once felt fast starts to struggle.

I break down these factors and how to fix them in more detail here: por qué muchas webs WordPress se vuelven lentas

WordPress sitemap issues before launch

ellie miguel — Thu, 19 Mar 2026 14:23:00 +0000

Part of the series: WordPress Pre-Launch Technical Checks

When a WordPress site is about to go live, most teams naturally focus on design, content and performance. Those are the visible parts, the ones everyone reviews.

The sitemap, on the other hand, usually sits in the background. It’s generated automatically, so it tends to be assumed that everything is fine.

But that’s not always the case. I’ve seen quite a few projects where the sitemap didn’t really reflect the final structure of the site, simply because no one checked it before launch.

Taking a quick look at it before delivery can save you from sending confusing signals right from the start.

What a sitemap actually does

An XML sitemap is basically a list of URLs that the site exposes for search engines to discover.

In WordPress, this is usually handled automatically. Core, SEO plugins or even performance tools can generate it without much setup.

That sounds convenient, and it is, but it also means the output is rarely reviewed in detail.

Why problems appear before launch

During development, sites go through a lot of changes. Pages are created, removed, hidden or reorganized as the structure evolves.

The sitemap, however, often keeps reflecting those intermediate steps. By the time the site is ready, it may still include URLs that no longer make sense, or miss some that do.

Since everything looks fine on the surface, this tends to go unnoticed.

What tends to go wrong

Outdated or temporary URLs still included

Test pages, drafts or temporary routes can end up in the sitemap if they were part of the process at some point.

Important pages missing

Sometimes key pages don’t appear at all, especially when custom content types or specific settings are involved.

Multiple sitemap generators

It’s not unusual to have more than one system generating sitemaps. WordPress core, an SEO plugin and even other tools can all produce their own version.

When that happens, search engines may pick up different sources with slightly different signals.

Assuming everything is correct without checking

This is probably the most common one. Because the sitemap is automatic, it’s easy to trust it without actually opening it and seeing what’s inside.

A quick check before launch

At this stage, it’s usually enough to open the sitemap and review it with a bit of attention. Check that it loads correctly, that the main pages are there, and that nothing unexpected is included.

It’s a simple step, but it helps make sure the site is sending clear discovery signals from day one.

Why this belongs in a launch checklist

Sitemaps don’t affect how a site looks or behaves for users, so they’re easy to ignore.

But they play a role in how search engines understand the structure of the site. If the sitemap is messy, that understanding can be slower or less accurate.

Including this check in a repeatable process keeps things cleaner from the beginning.

Where PreFlight fits in

PreFlight focuses on reviewing these kinds of technical details before a WordPress site is delivered or published. It’s about catching the things that don’t break anything, but still matter.

If you want to run a quick technical check before launch, you can start here: https://preflightstandard.com/

Final thought

The sitemap is easy to forget because it works in the background.

But making sure it reflects the final structure of the site before launch is a small step that helps everything stay aligned from the start.

7 common mistakes on private clinic websites

ellie miguel — Thu, 19 Mar 2026 14:14:00 +0000

Many clinic websites look good at first glance but still fail to generate trust or inquiries.

I run into this quite often when reviewing websites for private clinics. The issue is rarely the visual design. Most of the time, it’s about how information is structured and how easy it is to navigate.

One thing that shows up quickly is a lack of clarity. If a visitor needs more than a few seconds to understand what the clinic actually offers, they usually leave before exploring further.

This confusion often continues in the way treatments are explained. Technical language might sound precise, but it can create distance if patients don’t fully understand what they’re reading.

Contact options can also become a source of friction. Sometimes the phone number is hard to spot, or the form is buried somewhere in the page. Even small obstacles here can reduce the chances of someone reaching out.

Another pattern I see is how little visibility is given to the medical team. When there are no faces or profiles, the website feels more anonymous, and that directly affects trust.

Performance and usability also play a role, even when everything “seems” to work. Slight delays or awkward navigation can change the overall perception more than expected.

Over time, structural limitations tend to appear as well. When clinics try to add new services or professionals, the website doesn’t always adapt easily, and things start to feel disorganized.

And then there’s maintenance, which is often overlooked. Updates, security checks and small technical fixes might not be visible, but they are essential to keep everything running smoothly.

I explain these patterns in more detail, with examples, here: 7 errores muy comunes en webs de clínicas privadas