DEV Community: ellie miguel

What changes when a WordPress project is planned with clear criteria

ellie miguel — Tue, 12 May 2026 13:23:00 +0000

I’ve picked apart enough WordPress projects to know where the slow, expensive problems start: not in the code, but in the way decisions were made at the beginning. If you’re wondering how to choose a freelance WordPress professional, the sharpest filter is whether they bring judgment, not just execution.

Why starting with criteria matters

When a project begins with clear priorities, the rest becomes simpler. You stop piling features at random and start asking which parts of the site actually move the needle—conversion forms, page speed, content structure—so work is sequenced by impact rather than by convenience. From what I’ve seen, that upfront discipline reduces rework and keeps budgets honest.

How that difference shows up in practice

Take a plugin-heavy site that loads slowly and breaks after every update. A contractor who sees only the symptom will add caching or tweak the theme and call it done. A freelancer who starts with criteria will audit why plugins conflict, decide which are essential, and propose a controlled cleanup before adding anything new.

Or imagine a redesign focused on aesthetics. If nobody checks whether the contact flow converts, you might end up with a beautiful site that doesn’t capture leads. Starting with a small list of conversion goals steers design choices—form placement, button text, and validation—so visuals don’t outpace business needs.

Signs you’re hiring execution over judgment

Price becomes the first and only comparison. If bids are reduced to numbers without a clear list of priorities, you’re comparing hours, not approaches. That usually hides the fact that the work hasn’t been diagnosed.

Another common sign is an all-in-one promise: design, SEO, speed, copy, automations, and long-term support bundled with no diagnostic phase. That can mean the provider is selling a recipe instead of tailoring a solution, and recipes rarely survive real sites with legacy content and integrations.

What to look for when vetting a freelancer

Listen for diagnostic questions. A freelancer who asks about your traffic sources, the pages that bring leads, and what breaks most often is checking fit, not selling tools. Good questions reveal whether they understand the business behind the site.

Pay attention to how they prioritize. If they can explain which single change would deliver the most value this month, you’re talking to someone who can trade off scope for impact. That kind of trade-off is what prevents endless add-ons and surprise invoices.

Also look for scope clarity and follow-through. You want someone who defines what’s in and out of the sprint, how changes are tested, and who owns maintenance after launch. Continuity doesn’t mean a monthly subscription necessarily, but it does mean the project won’t need redoing the first time WordPress updates.

A short example

I once advised a service business that wanted a full redesign and a new booking flow at the same time. The freelancer they hired started with the redesign and only later discovered the booking form was built with an outdated plugin that prevented analytics and confirmation emails. We paused the redesign, fixed the form foundation, and then completed the visual work. It cost a few weeks but avoided a rebuild and made the redesign actually usable.

That kind of pause—planning over rushing—changes outcomes. It’s not glamorous, but it’s what separates a site that lasts from one that keeps getting patched.

If you want the full breakdown on the blog (https://elliemiguel.es/como-elegir-wordpress-freelance/), the longer version goes deeper into the trade-offs behind this.

What a WordPress Specialist Should Bring Beyond Installing Plugins

ellie miguel — Thu, 07 May 2026 13:22:00 +0000

I've inherited sites that "worked" for months and then stopped bringing leads overnight. That moment — when a site stops being a passive asset and becomes a business risk — is where a real specialist starts to matter.

Look for diagnosis, not just fixes

Installing a plugin or running updates feels like progress, but it often treats symptoms. A specialist will map causes: hosting limits, a heavy page builder, unoptimized media, or overlapping plugins. They run targeted checks, reproduce the failures, and explain which of those problems matters for your goals.

For example, a slow contact form could be caused by a misconfigured DNS, an overloaded PHP worker, or a plugin conflict. The quick fix is to replace the form plugin; the diagnostic approach traces where the bottleneck actually sits, so the same problem doesn't return a month later.

Prioritization that respects time and budget

Not every improvement deserves the same effort. A specialist translates technical debt into business choices: what to fix now, what to monitor, and what to leave until it matters. That judgment saves money because it prevents endless minor changes that don't move the needle.

In practice, this looks like a short roadmap rather than a long invoice—an honest take on low-impact tweaks versus structural work that will change how you publish, convert, or operate.

Safe workflows and predictable deployments

Doing changes directly on a live site can feel fast, but it's fragile. A professional will insist on staging environments, backups, and rollback plans so a routine update doesn't become downtime. This is not bureaucracy; it's how you turn accidental breaks into controlled experiments.

I've seen teams spend days recovering from a rushed edit that overwrote custom templates. With basic deployment discipline you can test a redesign, tweak performance settings, or switch a plugin without holding your breath.

Alignment with what the site should do

Beyond technical hygiene, a specialist looks at outcomes: does the site capture the right leads, filter clients, reduce manual work, or speed up a conversion funnel? If the tech doesn't help those goals, the site can be updated forever and still fail to deliver.

That often means changing non-technical things: simplifying content structure, rethinking forms, or limiting plugins that create editing friction. The point is to make the website easier to manage and more useful for the people who actually use it.

A quick example: when maintenance isn't enough

Imagine a site that loses 20% of form submissions after a plugin upgrade. Maintenance might keep versions current, but a specialist would ask why submissions are so fragile, test traffic spikes, audit third-party scripts, and propose a fix that stops the leak rather than papering over it. That difference—temporary patch versus durable fix—costs less over time.

If you want the full breakdown, with concrete questions to ask a candidate and a checklist for deciding between support, maintenance, or a rebuild, you'll find the complete guide on my blog: elliemiguel.es — full article (https://elliemiguel.es/cuando-conviene-una-freelance-wordpress/).

Before a redesign or new content: fix crawlability and site architecture on WordPress

ellie miguel — Tue, 05 May 2026 13:22:00 +0000

I’ve reviewed plenty of WordPress sites where teams go straight to a redesign or content sprint while the site’s foundation quietly sabotages their effort. Short version: if Google can’t find or understand your pages, prettier templates and new blog posts won’t move the needle.

Why crawlability and indexation matter first

Search engines don’t rank what they can’t see. That usually shows up as pages meant to be visible getting buried, while low-value URLs—tag archives, test pages, or thin plugin-generated content—end up in the index. From what I’ve seen, that creates two classic traps: a false sense of progress because analytics show traffic that’s either meaningless or misattributed, and a bad attempt to ‘fix’ rankings by adding more content on top of a broken base.

Concrete failures I keep finding (and what they feel like)

One site had dozens of old staging URLs still indexable; another relied on chained redirects after a migration so link equity leaked away. In practice, these problems look boring in a meeting: mixed signals in Search Console, crawl budget wasted, canonical tags that conflict with visible URLs. But the outcome is simple—the pages you care about don’t get prioritized.

Small technical fixes that change the game

Start with a focused crawl and a comparison between what your CMS outputs and what Google indexes. Fix canonical tags that point to different slugs, collapse redirect chains, and block irrelevant parameterized pages from being indexed. Those changes don’t always need a full redesign; often a careful cleanup of plugins, redirect rules, and robots settings will restore clarity quickly.

How to tell when redesign actually helps

Sometimes the theme or page builder is the bottleneck: pages that render terribly on mobile or inject tons of third-party scripts can erase the benefit of good content. I look for a pattern where technical debt keeps reappearing despite repeated fixes—if templates are inherently slow or incompatible with sensible caching, a redesign becomes the pragmatic route. But don’t jump there until you’ve ruled out simpler blocking issues.

If you want the full breakdown on the blog (https://elliemiguel.es/seo-tecnico-en-wordpress/), the longer version goes deeper into the trade-offs behind this.

What a services website actually needs to help you win clients

ellie miguel — Thu, 30 Apr 2026 13:22:00 +0000

I've worked on small agencies and solo consultants where the website looked fine but still felt like dead weight. After a few fixes you see the difference: fewer wasted calls, clearer briefs, and faster decisions.

Where most service sites trip up

First, the page says too much and means too little. A hero that tries to be clever about “solutions” or “growth” without naming who benefits forces visitors to interpret the offer for themselves. That initial guesswork weeds people out, but not the way you want—prospects leave because they can’t quickly confirm the fit.

Another common pattern is equal-weight content. Home, services, about and blog all scream for attention with the same visual priority. In practice, a website needs hierarchy: a clear path that nudges someone from recognizing a problem to choosing the right next step. When everything competes, nothing guides.

Proof is often present but weak. Testimonials that say “great work” without context, or portfolios that show screenshots without a sentence on the problem solved, leave the reader guessing. Mobile friction also sneaks in: slow pages, tiny CTAs or dense paragraphs end promising conversations before they begin.

One thing your site must do well

Make the first 5 seconds answer three small questions: who do you help, what outcome do you deliver, and what is the easiest next step to get a useful answer. If that’s clear, the visitor can self-select. If it’s not, every lead becomes a long, clarifying meeting.

Concretely, a service page that converts is not just a list of features. It explains a common client situation, describes the approach in plain terms, states limits or who it doesn't fit, and finishes with a contextual next step—an audit, a short call, or a scoped proposal—matching how ready the visitor is to decide. I’ve seen that arrangement reduce exploratory meetings by half, because people arrive already knowing whether they fit.

Proof belongs next to the decision, not buried at the bottom. Short case blurbs that mention the client type, the problem, and the result (time saved, revenue growth, fewer no-shows) are easier to evaluate than a long carousel of logos. It’s simple: help readers compare their situation to the examples you provide.

How to choose between tweak, rewrite or rebuild

There are three practical scenarios to separate in your head. If the site gets traffic but contacts are vague or low-value, start by fixing positioning, service pages and CTAs. If clients come by referral but the website fails to confirm choices, polish copy and evidence so referrals convert faster. If every change requires plugin surgery and pages load like molasses, the base is the problem—budget for development that stops adding technical debt.

Before deciding, do a quick audit: check mobile speed, read the hero out loud as if you’re the ideal client, and ask whether two or three real-world examples of your work are immediately visible. Often the right answer is smaller than you think: reorder, tighten the message, and put the right proof in front of the right reader.

If you want the full breakdown with examples and the diagnostic checklist I use when auditing sites, you'll find the complete guide on the blog: elliemiguel.es — Web de servicios para captar clientes (https://elliemiguel.es/web-de-servicios-para-captar-clientes/).

How a Psychologist’s Website Builds Trust Without Looking Generic

ellie miguel — Tue, 28 Apr 2026 13:21:00 +0000

I’ve worked with several therapists who felt their website was “nice but invisible.” What usually made the difference wasn’t a different palette or another stock photo; it was removing tiny moments of doubt.

Think of a psychology website as a short conversation that has to happen before someone makes a vulnerable call. The single design move that helps most is reducing decision friction: give quick, clear signals about who you help, how you work, and what the immediate next step is.

Three front‑page signals that actually lower friction

First, say who you help in plain language. Instead of a long list of conditions, a brief line like “individual therapy for adults facing anxiety and life transitions” frames the page. That tiny specificity stops people from guessing whether they belong here.

Second, explain your approach in a sentence or two rather than a paragraph of values. Describe the setting—online or in‑person, session length, and whether you offer short‑term focused work or open‑ended therapy. People don’t need your whole method on page one, they need to know roughly what to expect.

Third, make the next step obvious and low‑risk. A clear contact line, an estimate of wait time, or a short note on first‑session logistics reduces the anxiety around booking. When someone knows what happens after they click, hesitation drops.

What usually makes a site feel generic

Stock photos of smiling people and phrases like “a safe space to grow” don’t harm, but they rarely persuade. Those elements flatten personality; they tell visitors you’ve followed the template rather than thought about their moment of doubt.

Another common problem is trying to be everything to everyone. A long, unordered list of specialties reads like indecision. When nothing is prioritized, visitors can’t tell if your practice is a fit for their immediate concern.

There’s also the biography‑first trap. Long personal stories are valuable, but they belong after the basics. For someone deciding whether to contact you, a full CV may increase distance rather than trust.

Finally, small technical issues masquerade as design problems: slow mobile pages, broken forms, or hard‑to‑find contact details. Those frictions are louder than layout choices because they interrupt the action you actually want—a message, a call, an appointment.

A quick, practical check before starting a redesign

Look at your homepage for thirty seconds and ask three quick questions: Can I tell who this is for? Do I understand the setup (online or location)? Is the next step clear? If you can’t answer those fast, the site is adding friction.

In many cases a short content reorder, a clearer hero line, and fixing form or mobile issues will move the needle more than a full redesign. From what I’ve seen, an audit that isolates whether the problem is message, structure, or technical foundation saves time and money.

If you want the full breakdown on the blog (https://elliemiguel.es/diseno-web-para-psicologos/), the longer version goes deeper into the trade-offs behind this.

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.