Here is how we build service-area pages in WordPress so each one earns its place.

1. Decide which areas deserve a page

A page per suburb isn't a strategy. Start with areas where the business genuinely does work and can say something specific:

• jobs completed there, with photos
• staff or vans based nearby
• local rules that change the work (permits, building codes, council requirements)
• reviews from customers in that area

If you can't write three specific facts about an area, leave it on a single "Areas we serve" page instead.

2. Model areas as a custom post type

Areas are content, not settings, so give them their own post type. This keeps URLs clean (/areas/plano/) and lets editors manage them without touching the theme.

add_action( 'init', function () {
    register_post_type( 'service_area', [
        'label'        => 'Service areas',
        'public'       => true,
        'has_archive'  => 'areas',
        'rewrite'      => [ 'slug' => 'areas', 'with_front' => false ],
        'show_in_rest' => true, // needed for the block editor
        'supports'     => [ 'title', 'editor', 'excerpt', 'thumbnail', 'custom-fields' ],
        'menu_icon'    => 'dashicons-location',
    ] );
} );

Flush permalinks once after adding it (Settings, Permalinks, Save).

3. Store the facts as fields, not prose

Put the area-specific data in fields so the template can display it consistently and you can see at a glance which pages are thin:

add_action( 'init', function () {
    foreach ( [ 'area_region', 'area_jobs_count', 'area_local_note' ] as $key ) {
        register_post_meta( 'service_area', $key, [
            'type'          => 'string',
            'single'        => true,
            'show_in_rest'  => true,
            'auth_callback' => fn() => current_user_can( 'edit_posts' ),
        ] );
    }
} );

area_local_note is the important one: one or two sentences only a local would know, such as "Most homes in older parts of Irving still have galvanised pipes, so we check pressure before any fixture swap."

4. Build the template with a block pattern

In a block theme, create templates/single-service_area.html and lay it out with blocks. Use a pattern for the repeatable parts (services list, call-to-action) and leave the main content to the editor. The page should open with a short, specific answer: what you do in this area and how fast you get there.

Avoid auto-generating the body text. Templates should handle layout. People should write the words.

5. Add LocalBusiness schema once, and areaServed per page

Your business has one address. Don't invent a new one per city. Output LocalBusiness with the real address site-wide, and on each area page add areaServed:

add_action( 'wp_head', function () {
    if ( ! is_singular( 'service_area' ) ) return;
    $data = [
        '@context'   => 'https://schema.org',
        '@type'      => 'Service',
        'name'       => get_the_title() . ' services',
        'areaServed' => [ '@type' => 'City', 'name' => get_the_title() ],
        'provider'   => [ '@type' => 'LocalBusiness', 'name' => get_bloginfo( 'name' ), 'url' => home_url( '/' ) ],
    ];
    echo '<script type="application/ld+json">' . wp_json_encode( $data ) . '</script>';
} );

6. Link areas from real places

Link each area page from the "Areas we serve" archive and from relevant case studies or blog posts. A page reached only from a footer list of twenty cities looks like a doorway page.

7. Check for thin pages every quarter

A simple WP-CLI check flags pages with too little unique content:

wp post list --post_type=service_area --fields=ID,post_title --format=csv \
| tail -n +2 | while IFS=, read -r id title; do
  words=$(wp post get "$id" --field=post_content | wp eval 'echo str_word_count( wp_strip_all_tags( file_get_contents("php://stdin") ) );')
  echo "$title: $words words"
done

Anything under about 250 words with no local note should be improved or merged.

FAQ

Is a plugin better than a custom post type? Plugins that generate hundreds of location pages from one template produce exactly the thin content Google filters out. A custom post type with hand-written content is safer.

Should area pages target "near me" searches? No. "Near me" results depend on the searcher's location and your Google Business Profile, not on the words "near me" in your page.

How many area pages should a small business have? Usually three to ten: the places where you have real jobs, reviews and something specific to say.

We design and build WordPress sites for service businesses in the USA, UK, Canada and Australia, including service-area structures like this. See how we approach WordPress website design and development at Dzimark.

Here's how we add an AI chatbot to a WordPress build for a small business without failing Core Web Vitals. The pattern works for hosted widgets (Intercom, Tidio, Crisp and the like) and for a custom chatbot you host yourself.

The targets

Google's Core Web Vitals thresholds, from web.dev, at the 75th percentile of page loads:

• LCP (Largest Contentful Paint): 2.5 seconds or less
• INP (Interaction to Next Paint): 200 milliseconds or less
• CLS (Cumulative Layout Shift): 0.1 or less

A chat widget can hurt all three: it competes for bandwidth during the LCP window, its long JavaScript tasks block input (INP), and a launcher bubble or banner that pops in late can shift layout (CLS).

Step 1: Measure before you add anything

Run PageSpeed Insights on the homepage and one service page, and note the field data if the site has enough traffic, plus the lab numbers. Then add the vendor's default snippet on a staging copy and measure again. You want to see the cost in your own numbers, because it varies a lot between vendors.

Step 2: Replace the snippet with a facade

A facade is a lightweight fake launcher: a button that looks like the chat bubble but is just HTML and CSS. The real widget loads only when someone clicks it.

<button id="chat-facade" class="chat-facade" aria-label="Open chat">
  <svg aria-hidden="true" width="24" height="24" viewBox="0 0 24 24"><path d="M4 4h16v12H7l-3 3z"/></svg>
</button>

.chat-facade {
  position: fixed; right: 20px; bottom: 20px;
  width: 56px; height: 56px; border-radius: 50%;
  border: 0; cursor: pointer;
}

Because the button is fixed-position and present from the first paint, it doesn't shift anything (good for CLS).

Step 3: Load the real widget on intent

(function () {
  var loaded = false;
  function loadChat(openAfter) {
    if (loaded) return;
    loaded = true;
    var s = document.createElement('script');
    s.src = 'https://widget.example-chat.com/loader.js';
    s.async = true;
    s.onload = function () {
      if (openAfter && window.ExampleChat) window.ExampleChat.open();
      var f = document.getElementById('chat-facade');
      if (f) f.remove();
    };
    document.head.appendChild(s);
  }
  var btn = document.getElementById('chat-facade');
  if (btn) {
    btn.addEventListener('click', function () { loadChat(true); });
    btn.addEventListener('pointerenter', function () { loadChat(false); }, { once: true });
  }
})();

Loading on pointerenter warms the widget up a moment before the click on desktop; touch devices just load on tap. Replace the script URL and the open() call with your vendor's documented API.

Step 4: Enqueue it the WordPress way

Put the facade markup in your theme's footer (or a small plugin) and enqueue the script in the footer, deferred:

add_action('wp_enqueue_scripts', function () {
    wp_enqueue_script(
        'chat-facade',
        get_stylesheet_directory_uri() . '/js/chat-facade.js',
        [],
        '1.0.0',
        ['in_footer' => true, 'strategy' => 'defer']
    );
});

The strategy argument for wp_enqueue_script has been available since WordPress 6.3.

If you use a caching or optimisation plugin that "delays JavaScript until interaction", check that it isn't also trying to delay the chat vendor's own script in a way that breaks the click-to-open flow. Test it.

Step 5: Only load where it helps

Not every page needs chat. Service pages, pricing and contact usually do; blog posts often don't. A simple condition keeps the facade off pages where it adds nothing:

if (is_page(['pricing', 'contact']) || is_singular('service')) {
    // output facade markup
}

Step 6: Keep a custom chatbot light too

If the chatbot is your own (for example a retrieval-based assistant answering from your site content), the same rules apply:

• ship the chat UI as a separate bundle that loads on click
• stream responses so the first words appear quickly
• keep the API on a fast endpoint, and never call the model provider directly from the browser with a secret key

Step 7: Measure again

Re-run PageSpeed Insights on the same pages. With a facade, the homepage should look almost the same as before the widget was added, because nothing from the vendor loads until a visitor asks for it. Field data takes about 28 days to reflect the change in Search Console's Core Web Vitals report.

FAQ

Does a facade hurt chat engagement? In our experience the visible launcher is what drives clicks, and that stays the same. The only difference is a short load after the first click, which the pointerenter warm-up mostly hides.

What about proactive "Can I help?" pop-ups? They need the real widget loaded, so they cost performance. If you use them, trigger them after a delay or scroll depth, and make sure they don't push content around.

Can we do this with a page builder? Yes. Most builders let you add an HTML block for the facade and a custom script in the footer.

This is part of how we approach WordPress website design and development for businesses in the USA, UK, Canada and Australia: features go in without giving up speed.

The three metrics, as Google defines them at web.dev:

• LCP (Largest Contentful Paint): good is 2.5 seconds or less.
• INP (Interaction to Next Paint): good is 200 milliseconds or less. INP replaced FID as a Core Web Vital in March 2024.
• CLS (Cumulative Layout Shift): good is 0.1 or less.

Each is judged at the 75th percentile of real page loads, on mobile and desktop separately.

1. LCP: make the hero image cheap

On most small-business home pages the LCP element is the hero image or headline.

• Serve the hero as a properly sized WebP or AVIF. WordPress generates srcset sizes; make sure the theme passes a sensible sizes attribute rather than letting phones download the 2,560px version.
• Don't lazy-load the hero. WordPress core skips loading="lazy" on the first content image and adds fetchpriority="high" to the likely LCP image (since 6.3), but some themes and page builders override it. Check the rendered HTML.
• Replace hero sliders with a single image. A slider's first slide often loads after its JavaScript, which delays LCP.
• Preload the main web font, or use a system font stack for headings.

<!-- What you want to see in the rendered hero -->
<img src="hero-1200.webp" srcset="hero-768.webp 768w, hero-1200.webp 1200w"
     sizes="(max-width: 768px) 100vw, 1200px"
     width="1200" height="630" fetchpriority="high" alt="...">

2. INP: watch the third-party scripts

INP measures how quickly the page responds to taps and clicks. On WordPress the usual problems are:

• chat widgets, review carousels and cookie banners all initialising on load
• page-builder animation libraries attached to every section
• jQuery-heavy plugins running long tasks on scroll

What to do:

• Load chat widgets on interaction (on first scroll or a click on a "Chat" button) rather than on page load.
• Audit plugins: anything adding front-end JavaScript must justify it. Remove plugins whose job the block editor now does natively.
• Use Chrome DevTools' Performance panel and look for long tasks (over 50ms) on tap.

3. CLS: reserve space for everything

• Every image and embed needs width and height (or aspect-ratio) so the browser can reserve space. Block themes do this for core image blocks; custom HTML blocks often don't.
• Cookie banners should overlay the page, not push content down.
• Use font-display: swap with a fallback font whose metrics are close, or size-adjust, so text doesn't jump when the web font arrives.
• Ads, embeds and "announcement bars" injected by plugins after load are the usual culprits.

4. Theme and plugin choices that make this easier

• Block themes over heavy page builders. A block theme with theme.json keeps CSS small and lets you set typography and spacing once.
• One caching layer. Server or host-level page caching plus a single optimisation plugin. Stacking two optimisation plugins often breaks things.
• Image handling in one place. Either the host's image CDN or a plugin, not both.

5. Measure properly

• Lab tools (Lighthouse, PageSpeed Insights' lab section) are good for debugging but aren't what Google uses for Core Web Vitals.
• Field data comes from the Chrome UX Report, shown in PageSpeed Insights and in Search Console's Core Web Vitals report once the site has enough traffic.
• For a brand-new site, add the web-vitals JavaScript library and send the metrics to your analytics so you have real data before CrUX does.

import {onLCP, onINP, onCLS} from 'web-vitals';
[onLCP, onINP, onCLS].forEach(fn => fn(m => {
  navigator.sendBeacon('/vitals', JSON.stringify({name: m.name, value: m.value, id: m.id}));
}));

Pre-launch checklist

• Hero image sized, modern format, not lazy-loaded, fetchpriority="high"
• No hero slider
• At most two font families, main font preloaded or system stack
• Chat, reviews and other third-party widgets deferred until interaction
• Every image and embed has dimensions
• Cookie banner overlays content
• One caching layer, one optimisation plugin
• web-vitals reporting in place until CrUX data appears

Performance is one part of a WordPress website design brief, alongside accessibility, editing experience and security. If you'd like a team to handle all of it, here's how we approach WordPress design and development for businesses in the USA, UK, Canada and Australia.

FAQ

Does a fast host fix Core Web Vitals on its own? It helps server response time, which feeds LCP, but it doesn't fix layout shifts or slow scripts.

Are page builders always slow? Not always, but they usually add more markup, CSS and JavaScript than a block theme. Test the specific build.

Which Core Web Vital fails most often on small WordPress sites? In the sites we review it's usually LCP on mobile, from oversized or lazy-loaded hero images.

Sources: web.dev Core Web Vitals thresholds and INP announcement; WordPress core image loading optimisations (WordPress 6.3 field guide).

What actually changes

Shopify's path prefixes (/products/, /collections/, /pages/, /blogs/) are fixed. You can't recreate WooCommerce URLs one to one, so every indexed URL needs a 301.

Step 1: collect every URL that matters

Pull from three sources and merge them:

1. The WooCommerce XML sitemaps (Yoast or Rank Math usually expose /sitemap_index.xml).
2. Search Console: Performance → Pages, last 12 months. Export it; these are the URLs with real traffic.
3. Backlinks: any URL other sites link to, from your backlink tool of choice.

Merge, normalise (lowercase host, strip tracking parameters) and de-duplicate.

Step 2: map old to new with handles

Shopify handles are usually generated from the product title. If you import products with their WooCommerce slug as the handle, mapping becomes almost mechanical. A minimal Node script:

// map-redirects.js: node map-redirects.js old-urls.txt > redirects.csv
const fs = require('fs');
const urls = fs.readFileSync(process.argv[2], 'utf8').split('\n').filter(Boolean);

const rules = [
  [/^\/product\/([^/]+)\/?$/, (m) => `/products/${m[1]}`],
  [/^\/product-category\/(?:[^/]+\/)*([^/]+)\/?$/, (m) => `/collections/${m[1]}`],
  [/^\/blog\/([^/]+)\/?$/, (m) => `/blogs/news/${m[1]}`],
  [/^\/([^/]+)\/?$/, (m) => `/pages/${m[1]}`],
];

console.log('Redirect from,Redirect to');
for (const raw of urls) {
  const path = new URL(raw).pathname;
  if (path === '/') continue;
  const rule = rules.find(([re]) => re.test(path));
  if (!rule) { console.error('UNMAPPED', path); continue; }
  console.log(`${path},${rule[1](path.match(rule[0]))}`);
}

Anything printed as UNMAPPED needs a human decision. Nested categories need care: if two categories share a final slug (for example /men/shoes/ and /women/shoes/), make the collection handles unique and map each one by hand.

Step 3: import and test before DNS changes

• Import redirects.csv with the Import button on the URL redirects screen of the Shopify admin (/admin/redirects).
• Shopify only applies a redirect when no page exists at the old path, which is fine here because the old paths don't exist on Shopify.
• On the development store (or with the preview domain), request a sample of old paths and check each one returns a single 301 to a 200.

while read -r path; do
  curl -s -o /dev/null -w "%{http_code} %{redirect_url} $path\n" "https://your-store.myshopify.com$path"
done < sample-paths.txt

Step 4: keep the on-page signals

Redirects move the authority; the new page still has to deserve the ranking.

• Carry over SEO titles and meta descriptions (Shopify has fields for both on products, collections, pages and articles).
• Keep product descriptions and image alt text. Don't swap long, original copy for a short supplier text during the move.
• Recreate structured data: most Shopify themes output Product schema; check reviews and FAQ markup separately.
• Keep internal links in blog posts pointing at the new URLs, not through redirects.

Step 5: launch-week monitoring

• Submit the Shopify sitemap (/sitemap.xml) in Search Console.
• Crawl the full old-URL list again on launch day and fix any 404s.
• Watch Search Console's Pages report for "Not found (404)" and "Page with redirect" over the next few weeks.
• Compare clicks for the top 50 landing pages week by week against the old URLs.

FAQ

Will rankings drop after migrating? A short wobble is common while Google recrawls. A lasting drop usually means missing redirects, thinner content or lost internal links.

Can I remove /products/ from Shopify URLs? No, the prefixes are fixed.

Should I redirect deleted products to the homepage? No. Send them to the closest category (collection) or a replacement product; otherwise Google may treat them as soft 404s.

Do I need to keep the redirects forever? Keep them at least as long as the old URLs get traffic or links. There's no cost to leaving them in place.

We plan and run these moves for stores in the USA, UK, Canada and Australia. The details are on our WooCommerce to Shopify migration services page.

This post is the build pattern we use instead: retrieval from approved content, guardrails, human handoff and logging. It's model-agnostic. The same structure works with any of the major model providers.

1. Retrieval: answer only from approved content

The bot should answer from content the business has signed off, not from what the model "knows".

• Pick the sources: help-centre articles, policies (shipping, returns, warranty), product data and opening hours. Leave out internal wikis and old blog posts unless someone has reviewed them.
• Chunk by heading, not by a fixed character count, so each chunk is one self-contained answer.
• Store metadata with each chunk: source URL, last-updated date and owner. You'll need all three later.
• Show the source in the reply ("From our returns policy"), with a link. Customers trust it more, and wrong answers are easy to trace.
• Re-index on change. When a policy page is updated, its chunks should be replaced the same day, not at the next quarterly review.

2. Guardrails: decide what the bot must never do

Write these down before writing prompts:

• Stay in scope. Questions outside the approved content get a polite "I can't help with that here" plus a route to a person.
• No prices, legal terms or medical/financial advice unless they come word for word from a retrieved, approved source.
• A confidence rule. If retrieval returns nothing relevant (low similarity) or the sources conflict, the bot hands off instead of guessing.
• No actions without approval. If the bot can do things (book, refund, cancel), anything involving money or account changes needs a confirmation step, and refunds need a person.

3. Human handoff that actually works

A handoff that says "email us" loses the customer. Do it properly:

• Pass the whole transcript and the customer's details to the help desk (Zendesk, Freshdesk, HubSpot or a shared inbox) so nobody has to ask again.
• Tell the customer what happens next and when ("A person will reply by email within one business day").
• Outside office hours, say so, and collect contact details instead of leaving a live-chat promise hanging.

4. Logging and weekly review

• Log every conversation with the retrieved sources and the final answer.
• Redact personal data (emails, phone numbers, order IDs where possible) in logs used for review.
• Once a week, read the unanswered and handed-off questions. Most of them point to missing or unclear content. Fix the content, not the prompt.
• Track four numbers: resolution rate, handoff rate, unanswered questions and customer rating.

5. US-specific things to check with counsel

This isn't legal advice, but these come up with US clients:

• State privacy laws. Chat logs are personal information. California's CCPA as amended by the CPRA, and the growing list of similar state laws, cover notice, access and deletion requests. Set a retention period for logs and make sure you can delete a person's conversations on request.
• Bot disclosure. California's bot disclosure law (SB 1001) requires disclosure when a bot is used to incentivise a sale or influence a vote. Simplest rule: tell everyone they're talking to an AI assistant.
• Accessibility. The chat widget is part of your website: keyboard access, screen-reader labels and focus handling matter under the ADA expectations US businesses already face.

6. Launch checklist

• Sources listed, reviewed and dated
• Out-of-scope and no-price rules tested with 30+ real customer questions
• Low-confidence handoff tested
• Transcript reaches the help desk
• Office-hours message set
• AI disclosure shown at the start of the chat
• Log retention and deletion process agreed
• Widget keyboard- and screen-reader-tested
• Owner named for the weekly review

FAQ

RAG or fine-tuning? For support, retrieval first. Fine-tuning changes tone and format; it doesn't keep facts current. Your policies change, so retrieval is what keeps answers right.

How long does a pilot take? It depends on how ready the content is. Clean, current help articles make it quick; scattered PDFs and outdated pages take longer, because the content has to be fixed first.

Which channels? Start with the website. Add WhatsApp or the help desk widget once the answers are reliable on one channel.

We build this for US companies: AI chatbot development for US businesses.

This is the pattern we use. It needs no extra services beyond n8n and a channel your team already reads.

1. Give every production workflow an error workflow

n8n lets you set an error workflow in a workflow's settings. When a production run fails, n8n starts that error workflow, which begins with the Error Trigger node and receives details of the failed execution: the workflow name, the node that failed, the error message and a link to the execution.

Build one shared error workflow and point every production workflow at it. Ours does three things:

1. Formats a short message: workflow name, failed node, error text, execution link, time.
2. Posts it to a dedicated alerts channel (Slack, Teams or email).
3. Writes a row to an "automation incidents" sheet or table, so failures can be counted later.

One shared workflow means one place to change when the team moves from email to Slack, and nobody forgets to wire up alerts on a new workflow if it's part of your go-live checklist.

2. Retry what is temporary, stop on what is not

Some failures fix themselves: a rate limit, a timeout, a brief outage. Others never will: a deleted record, a missing permission, invalid data.

n8n nodes have a Retry On Fail setting with a number of tries and a wait between them. We switch it on for nodes that call external APIs, with a short wait, and leave it off for nodes where a retry could do harm, such as anything that sends a message or creates a payment. Retrying a "send email" step after a timeout can mean the customer gets the email twice.

The rule of thumb: retry reads freely, retry writes only when the target API is idempotent or you pass an idempotency key.

3. Decide per node what "failure" means

By default, a failing node stops the run. n8n also lets a node continue after an error, and recent versions can route errors to a separate error output so you can handle them inside the same workflow.

That is useful for batches. If you process 200 invoices and one is malformed, you usually want the other 199 to go through and the bad one to land in a review list, not a stopped workflow and 199 unprocessed invoices. Route the error branch to a "needs review" step that records which item failed and why.

For single, high-stakes actions, keep the default: stop, alert, investigate.

4. Fail on purpose when the data is wrong

Not every problem throws an error. An API can return a 200 with an empty list; a form can arrive with no email address; an AI step can return a category that doesn't exist.

Add checks after the steps that matter, and use n8n's Stop and Error node to fail the run deliberately when a check fails. A deliberate failure goes through the same error workflow and alert as any other, which is exactly what you want: "AI returned an unknown category: 'urgentish'" is a far better Monday message than a silently mis-routed ticket.

Good checks to start with:

• Required fields present (email, order ID, amount).
• Counts within expected ranges (zero new orders on a weekday is suspicious).
• AI outputs restricted to an allowed list of values.

5. Watch for runs that never start

Error workflows catch runs that fail. They don't catch runs that never happen, such as a webhook nobody calls any more because a form plugin was updated.

For important scheduled or webhook-driven workflows, add a small "heartbeat": the workflow writes its last successful run time somewhere, and a separate daily workflow checks that each timestamp is recent. If the weekly report hasn't run in eight days, someone hears about it.

6. Keep enough history to investigate

n8n stores execution data, and its retention depends on your plan or, when self-hosted, on your settings. Decide deliberately how long to keep failed executions so there is time to investigate, and how long to keep successful ones, bearing in mind that execution data can contain personal data. For workflows handling customer data, shorter retention plus your own incident log is usually the better balance.

A handover checklist

Before a workflow goes live, we confirm:

• Error workflow set in the workflow's settings.
• Retries on read/API nodes; none on non-idempotent writes.
• Batch steps route bad items to a review list.
• Data checks with Stop and Error after critical steps.
• Heartbeat for scheduled and webhook workflows.
• Execution retention set and documented.
• A named person who reads the alerts channel.

The last item matters most. An alert channel nobody owns is just a quieter way of failing.

If you would rather have this set up for you, this is the standard handover for our AI automation services, whether the workflows run on n8n, Make or Zapier.

FAQ

Does Zapier or Make have the same features? Both have their own error handling and notifications, with different names and options. The pattern (alert, retry carefully, check data, watch for silence) applies to all three.

Should every node retry on failure? No. Retry reads and idempotent calls. Be careful with anything that sends, charges or creates records.

What should go in an alert message? Workflow name, failed step, error text, a link to the execution and the time. Enough to start investigating without opening five tabs.

Where should alerts go? A dedicated channel that a named person reads every working day, not a general inbox.

More on choosing a tool: n8n vs Zapier vs Make on the Dzimark blog.

This post covers those three data sets, what Shopify accepts, and the scripts and checks we use on real migrations.

1. Customers

What transfers

Shopify's customer CSV import takes names, email, phone, addresses, tags, a note, tax-exempt status and email marketing consent. Export from WooCommerce with WP-CLI or a direct query, then reshape:

SELECT u.user_email AS email,
       MAX(CASE WHEN m.meta_key='billing_first_name' THEN m.meta_value END) AS first_name,
       MAX(CASE WHEN m.meta_key='billing_last_name'  THEN m.meta_value END) AS last_name,
       MAX(CASE WHEN m.meta_key='billing_phone'      THEN m.meta_value END) AS phone,
       MAX(CASE WHEN m.meta_key='billing_postcode'   THEN m.meta_value END) AS zip,
       MAX(CASE WHEN m.meta_key='billing_country'    THEN m.meta_value END) AS country
FROM wp_users u
JOIN wp_usermeta m ON m.user_id = u.ID
GROUP BY u.ID;

(Adjust the table prefix. If the store uses WooCommerce's newer customer lookup table, wc_customer_lookup is a cleaner source.)

What doesn't

Passwords. WordPress stores password hashes in its own format and Shopify won't import them. Every customer needs to set up access again. With Shopify's newer customer accounts, customers sign in with a one-time code sent to their email, which removes the password problem: plan a short email ("We've moved; sign in with your email") for launch day.

Marketing consent you can't prove. Only mark Accepts Email Marketing = yes for customers who actually opted in. If the WooCommerce store never recorded consent, import them as not subscribed. Under UK GDPR, Canada's CASL and Australia's Spam Act, importing everyone as subscribed is the fastest way to get complaints.

Checks

• Count unique emails before and after. Duplicates (same email, different case) are common in old WooCommerce stores; lowercase and dedupe first.
• Phone numbers must be in a valid format or the row fails. Normalise to E.164 (+61…, +44…) before import.

2. Orders

What transfers

Shopify's admin CSV import covers products and customers, not orders. Historical orders come in through the Admin API or an import app such as Matrixify. Either way:

• Import orders as archived and fulfilled, with notifications switched off, so nobody receives a "your order is confirmed" email for something they bought in 2021.
• Keep the original WooCommerce order number in a tag or note attribute (woo-order:10432). Support teams search by it for months.
• Match each order to its customer by email so it shows in the customer's account history.

What doesn't

• Payment tokens. Saved cards and recurring payment tokens belong to the payment gateway, not WooCommerce. If the store sells subscriptions, ask the gateway (for example Stripe) whether it can migrate tokens to the new setup before you promise "no one has to re-enter their card".
• Refund records in their original form. You can record refunds on imported orders, but most stores import the final state (total, refunded amount) and keep the WooCommerce export as the archive.

Checks

Reconcile totals per month: sum of WooCommerce order totals vs sum of imported Shopify order totals. A mismatch of more than a few cents usually means tax-inclusive vs tax-exclusive prices were mixed up.

3. Reviews

WooCommerce stores product reviews as WordPress comments with comment_type = 'review' and the star rating in comment meta:

SELECT p.post_name AS product_handle,
       c.comment_author AS reviewer_name,
       c.comment_author_email AS reviewer_email,
       c.comment_content AS body,
       cm.meta_value AS rating,
       c.comment_date AS created_at
FROM wp_comments c
JOIN wp_posts p ON p.ID = c.comment_post_ID
LEFT JOIN wp_commentmeta cm ON cm.comment_id = c.comment_ID AND cm.meta_key = 'rating'
WHERE c.comment_type = 'review' AND c.comment_approved = '1';

Shopify has no built-in product review store, so pick the review app first, then export to that app's CSV template. The join key is the product handle: if you change handles during the migration (dropping -2 suffixes, for example), map old to new before you import reviews, or they attach to nothing.

Keep the original review dates. Reviews that all appear "today" look fake to shoppers.

4. The launch-day order

1. Final product and customer delta import (anything created since the test run).
2. Orders delta.
3. Reviews.
4. Redirects (product, category, page and blog URLs).
5. Customer email: how to sign in on the new store.

FAQ

Can customers keep their loyalty points? Only if you export the balances and import them into the new loyalty app. Points live in the WooCommerce plugin's tables, so check that plugin's export options early.

Do I need to import every old order? Not always. Many stores import two or three years and keep the rest in an archive export. Decide with whoever handles returns and accounting.

Will imported reviews show stars in Google? Only if the review app outputs valid structured data on product pages. Check with Google's Rich Results Test after launch.

If you'd rather hand this part to a team that has done it before, our WooCommerce to Shopify migration services cover customers, orders, reviews and redirects, with a reconciliation report at the end.

Here is the checklist we follow.

1. Know what Webflow's export gives you (and what it doesn't)

Webflow's code export gives you static HTML, CSS, JavaScript and assets. According to Webflow's own help centre, CMS, e-commerce, user accounts and localized content are not included in exported code, and Collection lists show their empty state.

So treat the export as a design reference, not as a site. The content comes out separately: each CMS Collection can be exported as a CSV from the Collection settings.

2. Build the URL inventory first

Before touching WordPress, list every URL that exists or has existed:

• Crawl the live site (Screaming Frog or any crawler) for every 200 URL.
• Pull the sitemap at /sitemap.xml.
• Export pages with impressions from Google Search Console (last 16 months).
• Export Webflow's existing 301 redirects from Site settings > Publishing.

Merge these into one sheet with columns: old_url, type (static page / collection item / asset), new_url, status.

3. Map Collections to post types

Each Webflow Collection becomes a WordPress custom post type (or the default post for a blog). Map fields one by one:

Keep slugs identical where you can. If Webflow served collection items at /blog/my-post, register the post type with a matching rewrite slug so you don't need a redirect at all:

register_post_type( 'case_study', [
  'public'       => true,
  'show_in_rest' => true,
  'has_archive'  => true,
  'rewrite'      => [ 'slug' => 'case-studies', 'with_front' => false ],
  'supports'     => [ 'title', 'editor', 'thumbnail', 'excerpt' ],
] );

4. Import the CSVs

For small sites, WP All Import or a short WP-CLI script works. A minimal WP-CLI approach:

wp eval-file import-case-studies.php case-studies.csv

Inside the script: read each row, wp_insert_post() with the mapped fields, download images into the media library with media_sideload_image(), and store the old Webflow item ID in post meta so you can re-run the import without duplicates.

Rich text from Webflow comes out as HTML. Import it as HTML first, then convert to blocks in the editor (or with the block converter) and spot-check headings, embeds and links.

5. Rebuild the design as a block theme

Use the Webflow export as the visual reference. Build a block theme with theme.json for colours, type scale and spacing, and patterns for repeated sections. Lock patterns that marketing shouldn't restructure. This is the step that gives the client the "edit without breaking it" experience they had in Webflow's editor.

6. Redirects, then launch

• Any URL whose path changes gets a 301 to its new URL. Use the server or a redirect plugin, not JavaScript.
• Carry over Webflow's existing redirects too (chains like A → B → C should become A → C).
• Check canonical tags, titles and meta descriptions on the 20 pages with the most impressions.
• After the DNS switch, crawl the old URL list and confirm every row returns 200 or a single 301.
• Submit the new sitemap in Search Console and watch the Pages report for two weeks.

7. Things that are easy to miss

• Forms. Webflow form submissions live in Webflow. Export them before you cancel the plan, and rebuild forms with spam protection on WordPress.
• Asset URLs. Images and PDFs linked from other sites point at Webflow's CDN. Re-host important PDFs and redirect where you can.
• Interactions. Complex Webflow interactions need rebuilding in CSS or a small script. Agree with the client which ones matter.
• Localized pages. If the Webflow site used Localization, plan the WordPress multilingual setup (WPML or Polylang) before importing.

Wrap-up

A Webflow-to-WordPress move is mostly a content and URL project with a theme build attached. Get the URL inventory and the Collection mapping right, and the rankings usually come through the move intact.

If you are a business owner planning this, our WordPress website design and development team handles migrations like this for clients in the USA, UK, Canada and Australia.

1. Use a block theme and put the design system in theme.json

Classic themes scatter design decisions across PHP templates, the Customizer and CSS. A block theme puts most of them in one file, theme.json, which the editor reads. That means editors only see the colours, fonts and spacing you allow.

{
  "$schema": "https://schemas.wp.org/trunk/theme.json",
  "version": 3,
  "settings": {
    "appearanceTools": false,
    "color": {
      "custom": false,
      "customGradient": false,
      "defaultPalette": false,
      "palette": [
        { "slug": "brand", "color": "#0B3D91", "name": "Brand" },
        { "slug": "accent", "color": "#F2A900", "name": "Accent" },
        { "slug": "ink", "color": "#1A1A1A", "name": "Ink" },
        { "slug": "paper", "color": "#FFFFFF", "name": "Paper" }
      ]
    },
    "typography": {
      "customFontSize": false,
      "fontSizes": [
        { "slug": "body", "size": "1.0625rem", "name": "Body" },
        { "slug": "lead", "size": "1.25rem", "name": "Lead" },
        { "slug": "h2", "size": "clamp(1.6rem, 3vw, 2.2rem)", "name": "Heading" }
      ]
    },
    "spacing": { "customSpacingSize": false, "units": ["rem", "%"] },
    "layout": { "contentSize": "720px", "wideSize": "1200px" }
  }
}

Turning off custom, customFontSize and defaultPalette is the single most effective guard rail. Editors can still choose, but only from the brand's options. Pick palette pairs that pass WCAG contrast (4.5:1 for body text) so editors can't create an inaccessible combination by accident.

2. Give editors patterns, not blank pages

Most "broken" pages come from people building layouts from scratch. Register the 6–10 sections the business actually needs (service hero, three-column benefits, testimonial, FAQ, call to action) as block patterns, and lock the structure where it matters:

<?php
/**
 * Title: Service call to action
 * Slug: acme/service-cta
 * Categories: call-to-action
 * Block Types: core/post-content
 */
?>
<!-- wp:group {"lock":{"move":false,"remove":true},"backgroundColor":"brand","textColor":"paper","layout":{"type":"constrained"}} -->
<div class="wp-block-group has-paper-color has-brand-background-color has-text-color has-background">
  <!-- wp:heading {"level":2} --><h2>Ready to talk about your project?</h2><!-- /wp:heading -->
  <!-- wp:paragraph --><p>Tell us what you need and we'll reply within one business day.</p><!-- /wp:paragraph -->
  <!-- wp:buttons --><div class="wp-block-buttons"><!-- wp:button --><div class="wp-block-button"><a class="wp-block-button__link">Book a call</a></div><!-- /wp:button --></div><!-- /wp:buttons -->
</div>
<!-- /wp:group -->

Drop the file in /patterns and WordPress registers it automatically. With "remove": true, editors can change the words but can't delete the wrapper and leave orphaned buttons behind.

For page types that should always share one structure (service pages, location pages), add a template with the patterns already in place, so "Add new service page" starts 80% done.

3. Restrict the block inserter

Editors don't need 90+ core blocks. Filter the allowed list per post type:

add_filter( 'allowed_block_types_all', function ( $allowed, $context ) {
    if ( isset( $context->post ) && 'page' === $context->post->post_type ) {
        return array(
            'core/paragraph', 'core/heading', 'core/list', 'core/list-item',
            'core/image', 'core/buttons', 'core/button', 'core/group',
            'core/columns', 'core/column', 'core/details', 'core/pattern',
            'core/block', // synced patterns
        );
    }
    return $allowed;
}, 10, 2 );

Fewer choices means faster editing and fewer support emails.

4. Keep the plugin list short and owned

Every plugin is code you're asking the client to keep updated. Our rule of thumb for a brochure or lead-generation site:

• One SEO plugin, one forms plugin, one backup and one security approach. Nothing that duplicates core features.
• No page builder on top of a block theme. Two layout systems is how sites get slow.
• Each plugin gets a named owner and a note in the handover doc: why it's there and what breaks without it.

Then set up automatic minor updates, a staging copy for major ones, and daily off-site backups you have actually restored once.

5. Check performance and accessibility before handover

Measure Core Web Vitals on a mid-range phone, not your laptop. Google's "good" thresholds are LCP ≤ 2.5 s, INP ≤ 200 ms and CLS ≤ 0.1. Typical WordPress wins are serving correctly sized images, loading only the CSS the blocks on the page actually use, and keeping third-party scripts (chat widgets, trackers) to a minimum.

Run an automated accessibility check (axe or WAVE), then test keyboard navigation and headings by hand. That matters for ADA expectations in the US, the Equality Act in the UK, AODA in Ontario and the DDA in Australia.

6. The handover

A 30-minute recorded walkthrough plus a one-page doc covering:

• how to add each page type from its template;
• which patterns exist and when to use them;
• what not to touch (theme, plugins, permalinks);
• who to call, and what's covered by support.

That's the difference between a site the client owns and a site that slowly breaks.

We build WordPress sites this way for businesses in the USA, UK, Canada and Australia. If you'd like the business side of it (scope, redesigns without losing rankings, WooCommerce), here's our WordPress website design and development page.

FAQ

Do block themes work with WooCommerce? Yes. WooCommerce ships block-based cart, checkout and product templates that a block theme can style through theme.json.

Can I lock patterns so editors can't change the design at all? Use "lock": {"move": true, "remove": true} on the wrapper, plus templateLock on templates. Leave text editable, or the site stops being self-service.

Is a page builder ever the right choice? For sites already deep in a builder, a rebuild isn't always worth it. For new builds we prefer core blocks: fewer dependencies and lighter pages.

1. Install it locally

Use LocalWP or XAMPP so you can break things safely. Learn the dashboard: posts vs pages, menus, media, users and roles.

2. Build a complete site without code

Pick a free block theme and build a five-page site for an imaginary business with the block editor: home, services, about, blog, contact. Learn reusable patterns and the site editor.

3. Learn the plugins every client uses

A form plugin, an SEO plugin, a caching plugin and a backup plugin. Set each one up properly and understand what it changes. Know why you shouldn't install twenty plugins.

4. Add WooCommerce

Create a small shop with simple and variable products, shipping zones and a test payment method. Most freelance WordPress work in India involves a store at some point.

5. Start customising with code

Create a child theme. Add CSS, then a small function in functions.php, then a custom template. This is where your HTML, CSS and basic PHP start to pay off.

6. Handle the boring, important parts

Moving a site from local to live, updating safely, restoring from a backup, and basic security (strong passwords, limited admin accounts, updates).

Finish with two sites in your portfolio: a business site and a small store, both live.

From Dzimark Training, Mohali. Our WordPress course in Chandigarh and Mohali follows this path with live projects.

Here's the setup we use, and an honest list of what it won't find.

Install

npm i -D @playwright/test @axe-core/playwright
npx playwright install

@axe-core/playwright wraps Deque's open source axe-core engine and runs it inside a Playwright page.

The test

// tests/a11y.spec.ts
import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';

const pages = ['/', '/contact/', '/products/', '/checkout/'];

for (const path of pages) {
  test(`no automatically detectable WCAG A/AA issues on ${path}`, async ({ page }) => {
    await page.goto(path);

    const results = await new AxeBuilder({ page })
      .withTags(['wcag2a', 'wcag2aa', 'wcag21a', 'wcag21aa', 'wcag22aa'])
      .analyze();

    expect(results.violations).toEqual([]);
  });
}

Set baseURL in playwright.config.ts to your preview deployment and run it on every PR.

A few things that make it useful rather than noisy:

• Tag filter. withTags limits the run to WCAG A and AA rules (2.0, 2.1 and 2.2). Without it, axe also reports best-practice rules that aren't WCAG failures, which makes the report harder to triage.
• Test states, not just pages. Open the menu, trigger a form error, open the cookie banner, then run axe again. Many failures only exist in those states.
• Scope third-party widgets. .exclude('#chat-widget') lets you separate your own bugs from a vendor's, but keep a list of what you excluded and raise it with the vendor.
• Readable output. On failure, log violation.id, violation.help and node.target for each node so the developer can find the element.

for (const v of results.violations) {
  console.log(`${v.id}: ${v.help}`);
  for (const n of v.nodes) console.log('  ', n.target.join(' '));
}

What this catches well

• Images without alt attributes
• Form inputs without accessible names
• Colour contrast below 4.5:1 (normal text) or 3:1 (large text)
• Buttons and links with no text
• Missing document language, duplicate IDs referenced by ARIA, invalid ARIA attributes

What it can't catch

W3C's own guidance on evaluation tools says tools can't determine accessibility on their own; human judgement is needed. In our audits the issues that need a person are usually:

• Alt text quality. axe knows alt exists, not whether it describes the image.
• Keyboard flow. Tab order that makes sense, focus that doesn't vanish into a hidden menu, and modals that trap focus correctly and release it on close.
• Focus Not Obscured (WCAG 2.2, 2.4.11). A sticky header covering the focused element is easy to miss automatically.
• Target Size (2.5.8) in real layouts, especially icon buttons in dense mobile headers.
• Dragging Movements (2.5.7). Sliders and drag-and-drop lists need a click or tap alternative.
• Accessible Authentication (3.3.8). Login flows that block paste or rely on a puzzle without an alternative.
• Screen reader announcements. Whether a cart update or form error is announced at all.

So treat a green CI run as "no known automatic failures", not "accessible". Pair it with a short manual script per release: keyboard through the main journey, zoom to 200%, and one pass with VoiceOver or NVDA.

Where this fits

For US sites this is part of what the ADA guidance points to (WCAG as the practical benchmark). In the UK it supports the Equality Act's anticipatory duty, in Ontario the AODA's WCAG 2.0 AA rule, and in the EU the European Accessibility Act via EN 301 549. The CI pass doesn't change your legal position, but it stops regressions between audits.

If you'd like the manual half done by people who do it every week, Dzimark runs WCAG 2.2 AA website accessibility audits with a prioritised fix list.

FAQ

Does axe-core support WCAG 2.2? Yes. Use the wcag22aa tag (alongside the 2.0 and 2.1 tags) to include the 2.2 AA rules it can test.

Can I run it on a logged-in page? Yes. Use Playwright's storageState to reuse an authenticated session before calling analyze().

Will zero violations make my site compliant? No. Automated tools cover only part of WCAG; manual keyboard and screen reader testing is still required.

Sources: Playwright docs, "Accessibility testing"; axe-core rule tags (GitHub, dequelabs/axe-core); W3C WAI "Selecting Web Accessibility Evaluation Tools"; W3C "What's New in WCAG 2.2".