Blog

Under Settings → General, WordPress has two fields: WordPress Address (URL) and Site Address (URL). Change them and the site answers on the new domain within seconds. The old domain is still in your post content, theme options, plugin settings, inbound links, Google’s index and, on a store, your payment connection.

So a domain change is a sequence of separate jobs, and each one can fail on its own. The order below is the one WordPress’s own migration handbook and Google’s site-move guidance support. Before you start, have a backup of files and database that you have actually restored somewhere, and keep it until the new domain has been running cleanly for weeks.

Is this a domain change, a host move, or both?

A domain-only change leaves the files and database on the same server. You point the new domain at the server and update what WordPress stores. A host move copies files and the database to a new server. The handbook notes that if you keep the same domain, you can usually move hosts without touching the site URLs at all.

Doing both at once adds problems a domain change alone never has: database credentials and $table_prefix in wp-config.php, a different PHP version, missing files. If you can, split the work. Move hosts first, confirm everything works, then change the domain. Leave the permalink structure and the design alone while you do either one. When three things change together and traffic drops, you can’t tell which one caused it.

What has to be ready before you touch WordPress

Three things, in this order.

• The new domain reaches your server. Add it at your host as an alias, add-on or primary domain, then point DNS at the server. If email runs on the domain, change only the A or CNAME records. Kinsta’s migration docs say the same: switching nameservers can drop your MX records, and the mail goes with them.
• HTTPS works on the new domain. Issue the certificate for both new-domain.com and www.new-domain.com. WooCommerce’s SSL docs warn that switching a site to HTTPS before the certificate is valid can make it inaccessible.
• The old domain keeps a valid certificate. An HTTPS visitor has to finish the secure connection before your server can send them a redirect. An expired certificate on the old domain means a browser warning in place of a redirect.

Test it by opening https://new-domain.com. If the browser accepts the certificate and you land on the old domain, that is the right result at this stage. It proves the request reached your WordPress install, which is still redirecting to the address it has stored.

How to change the domain, step by step

1. Update the two addresses. In Settings → General, set both fields to https://new-domain.com. Leave them different only if WordPress core sits in a subdirectory on purpose. Saving logs you out because login cookies belong to a domain, so log in again at new-domain.com/wp-admin. If the fields are greyed out, WP_HOME or WP_SITEURL is defined in wp-config.php. The wp-config handbook page explains that these constants override the dashboard but never update the database. Edit them too, or remove them once the database holds the new values.
2. Replace the old URLs stored in the database. See the next section. This is the step people skip most often.
3. Refresh permalinks and caches. Open Settings → Permalinks and click Save without changing anything. If you have custom rules in .htaccess, check they survived. Then clear every cache: the caching plugin, the host’s server cache, the CDN and any object cache. A homepage that loads while posts return 404 almost always means stale rewrite rules or a cache. Our guide to permalinks that stop working covers that case.
4. Redirect the old domain, page to page. See the redirects section below.
5. Tell Google. Verify both domains in Search Console. Once the redirects are live, submit Change of Address from the old property. Then submit the new sitemap and check that robots.txt and Settings → Reading are not blocking search engines.
6. Test as a visitor. In a private window, open a post, an archive, a media-heavy page and your contact form. Submit the form and confirm the email arrives. Open the browser console and look for mixed-content warnings and redirect loops.

Why a find-and-replace in phpMyAdmin breaks settings

Plugins and themes save settings as PHP-serialized data, and that format records the length of every string. Run a raw SQL REPLACE() and swap old-domain.com for a name of a different length, and the recorded lengths no longer match. PHP can’t read the value, so the widget, theme option or plugin setting silently falls back to its default.

The handbook recommends a tool that rewrites the lengths correctly. With command-line access, use WP-CLI’s search-replace:

wp search-replace 'https://old-domain.com' 'https://new-domain.com' --skip-columns=guid --dry-run
wp search-replace 'https://old-domain.com' 'https://new-domain.com' --skip-columns=guid

Read the dry run’s table counts before you run the real thing. Repeat for http:// and www forms if your site still has them. Always include the scheme in the search string. A bare old-domain.com also rewrites info@old-domain.com in your forms and notification settings. Skip guid because WordPress says post GUIDs should never change. On multisite, WP-CLI only touches the current site’s tables unless you add --network. The handbook calls multisite domain changes “more complicated” and asks for a manual review of the network tables. Our multisite setup guide explains which domain values live where.

Without SSH, use Better Search Replace. It handles serialized data, lets you pick tables and offers a dry run. Page builders often keep their own generated CSS with absolute URLs, so regenerate those files from the builder’s tools screen afterwards. Then search the page source on the live site for the old domain. A clean report from the tool tells you what it processed, which is not the same as every URL a visitor sees.

Why redirects decide the SEO outcome

Every bookmark, backlink and search result points at the old domain. Google’s site-move documentation asks for server-side 301 or 308 redirects from each old URL to its matching new URL, in one hop. Keep them for at least a year. Sending every old URL to the homepage is the classic mistake: Google can treat those as soft 404s, and visitors lose the page they asked for.

If your paths stay the same, one rule on the old domain handles it. On Apache, put it at the top of .htaccess, above the WordPress block:

RewriteEngine On
RewriteCond %{HTTP_HOST} ^(www\.)?old-domain\.com$ [NC]
RewriteRule ^(.*)$ https://new-domain.com/$1 [R=301,L]

This keeps the path, so old-domain.com/services/ lands on new-domain.com/services/. Test the HTTP, HTTPS, www and non-www versions of a few deep URLs and check that each one takes a single hop. Update any existing redirect rules that still point at the old domain, or they will turn into chains. On Nginx or a managed host, use the host’s redirect tool. Our guides to htaccess 301 redirects and how 301s affect SEO go further.

Keep renewing the old domain after the year is up. The redirects stop working the day the registration lapses, and someone else can buy the domain and its backlinks.

What changes on a WooCommerce store

Payments notice the new URL. WooCommerce’s WooPayments Safe Mode docs say a new domain, a clone, or two URLs pointing at one install can trigger Safe Mode. Choose “Transfer your connection” to keep your account and history. “Create a fresh connection” starts over without the history. Payments can carry on in Safe Mode, but dispute and refund updates may not arrive reliably.

WooCommerce Subscriptions compares the current URL with the one stored at activation. When they differ, it switches to staging behaviour and turns off automatic payments and subscription emails. Confirm the live status after the move. If an old copy of the site is still running, shut it down. The same docs warn that a duplicate can keep processing real renewals. Then place a test order, and check refunds and renewal settings as well as checkout.

What a correct result looks like

The admin stays on the new domain after you log in again. Searching the page source of a few pages finds no internal references to the old domain. Every old deep link arrives at its matching page in one 301. The form email arrives. Search Console shows the new sitemap being read. On a store, WooPayments shows no Safe Mode notice and Subscriptions reports itself as live.

Expect search traffic to wobble anyway. Google calls temporary fluctuation normal and says a small or medium site can take a few weeks or more to settle. Search Engine Journal’s study of 892 domain migrations found an average of 523 days to win back estimated organic traffic, and 17% had not recovered after 1,000 days. Those figures come from third-party traffic estimates across all kinds of sites, so treat them as a reason to get the redirects right, not as a forecast for your site.

If something went wrong

Match the symptom to the cause before you change anything else.

• Locked out, or the site sends you to the wrong place. You probably changed the URLs before the new domain resolved. Set them back with wp option update home and wp option update siteurl, or edit the home and siteurl rows of wp_options in phpMyAdmin. Defining WP_HOME and WP_SITEURL also gets you in, as a temporary fix. Our login troubleshooting guide covers the rest.
• ERR_TOO_MANY_REDIRECTS. Usually the two URL fields disagree on http versus https or www, or .htaccess, the host and a CDN are each forcing a different version.
• Redirects back to the old domain. A constant in wp-config.php, a cached redirect, or stored URLs the replace missed.
• “Error establishing a database connection” or a white screen. This almost always means a host move happened at the same time. Check the credentials and $table_prefix in wp-config.php.
• The browser can’t find the domain at all. That is DNS, not WordPress. See our guide to DNS_PROBE_FINISHED_BAD_CONFIG.

Stop and restore the backup if the admin stays unreachable, errors appear across the site, or settings look corrupted and you can’t say why. On a store, write down every order placed since the backup before you restore over it. If you would rather hand off the WordPress side, SiteSelf can run the site changes through chat: the search-replace and redirects with hosting access, then a fetch of the changed pages to check them. The DNS, registrar and Search Console steps stay with you.

Frequently asked questions

A price changed yesterday, the Saturday hours are wrong, or there’s a typo in the homepage headline. Typing the fix takes ten seconds. Most of the time goes into finding where WordPress keeps that sentence. On a plain block editor page the steps are short. On a site with a page builder, a block theme, WooCommerce or a commercial theme, the same visible sentence could be stored in one of six places.

Start with the basic steps. Then use the table further down to track text that isn’t where you expected. For the wider picture of how pages are put together, see our guide to editing pages in WordPress safely.

How do you edit text on a normal WordPress page?

Open the page, click the text, type, and press Save or Update. WordPress keeps text inside blocks, and the Paragraph block holds ordinary body text. Here are the steps in full:

1. Open the right item. Go to Pages > All Pages (or Posts > All Posts), hover over the title and click Edit. Check the status column first, so you don’t edit an old draft or a duplicate called “Home (copy)”.
2. Select the block. Click the sentence. A small toolbar appears above it, showing which block you selected. On long pages, open List View from the top toolbar and jump straight to the block.
3. Edit the words. Type the change. Ctrl+Z (Cmd+Z on a Mac) undoes a mistake.
4. Format with the right tool. Bold, italic and links are in the block toolbar. Size, colour and spacing are in the Settings sidebar, opened from the panel icon at the top right. If you want a heading, use a Heading block. Large bold text is not a heading to a screen reader or a search engine.
5. Save or publish on purpose. Save draft keeps the change private. Publish or Update makes it live. Preview shows roughly how the page will look.
6. Check the live page. Open the public URL in a private window. Read the edited sentence and the text around it, then click any link you touched.

It worked if the new wording shows on the live page, the layout around it is unchanged, and links still go where they should. If the page opened but the sentence isn’t in the editor, the text lives somewhere else. Use the next section to find it.

The text isn’t in the editor. Where does it live?

It belongs to something other than the page. WordPress.org’s FAQ on changes that don’t appear lists editing in the wrong location as one of the usual causes, alongside caching. Match what you see to the table below.

Templates and synced patterns change every page that uses them

Headers, footers and some page sections on block themes come from templates and template parts. WordPress.org’s Site Editor Pages documentation says template blocks stay locked while you edit a page, until you choose to enable template editing. That lock is there for a reason. Once you edit the template, the change shows on every page built from it.

The homepage often catches people out. WordPress.org’s guide to the Site Editor explains that a Front Page template can take priority over the page you picked in Settings > Reading. If you changed the setting and nothing moved, the template is winning. Our guides to editing your WordPress homepage and changing footer text safely cover both cases step by step.

Synced patterns, once called reusable blocks, are shared in the same way. WordPress.org’s synced patterns documentation says that editing one updates it everywhere it is used. If you want to change it on one page only, choose Detach pattern. The detached copy is now ordinary content and won’t receive future changes to the shared pattern. Detach only when that is what you want.

Page builder text has to be edited in the builder

W3Techs detects Elementor on 31.5% of WordPress sites in its November 2026 figures. That means many readers are not editing text in the block editor at all. In Elementor, text sits in the Text Editor widget. Open the page with the builder, click the widget, edit it in the left panel or directly on the canvas, then click Update inside the builder. Divi text modules and Beaver Builder modules work the same way.

Don’t switch editors. Builders store their content separately from normal post content, so editing in the ordinary WordPress screen can leave the builder version untouched. A wordpress.org support thread from 2024 followed exactly that problem on a Beaver Builder site: the edits had been made in the WordPress editor, and a builder cache made the confusion worse. Volunteers advised sticking to one editor for each piece of content.

WooCommerce text is split across several places

Each product has two text fields. WooCommerce’s Product Editor documentation lists the product description (usually shown in a tab below the product) separately from the short description (usually shown next to the price). If you edit one, the other stays as it was. Where those fields appear on the page is set by the Single Product template.

Checkout and shop pages are harder. The checkout page body often contains nothing but a shortcode, and any extra text may come from the theme’s Customizer options. An r/woocommerce thread from 2025 found that a shop page description was generated by the theme. The poster fixed it by editing a theme file, and replies pointed out that the next theme update would wipe that change. A child theme override keeps the edit through updates.

Why won’t WordPress save my text?

If you see a red notice in the editor, the problem is not caching. The save failed. These are the common causes and what to try for each.

“Updating failed. The response is not a valid JSON response.” The block editor saves through the REST API at /wp-json/, and something interrupted that request. The fixes that keep coming up in wordpress.org support threads are:

• Open Settings > Permalinks and click Save without changing anything.
• Check Tools > Site Health for REST API errors.
• Make sure the WordPress Address and Site Address under Settings > General match.
• Ask your host whether a firewall or ModSecurity rule is blocking /wp-json/.

A plugin or theme conflict. WordPress.org’s troubleshooting FAQ names plugins competing over JavaScript as a cause of editor problems. Test on a staging copy, not on the live site that visitors use. The Health Check & Troubleshooting plugin turns plugins off for your session only, but its directory listing currently warns that it hasn’t been tested with the latest three major WordPress releases. Use staging if your host offers it. Switching to the Classic Editor can get the page saved, but the conflict is still there.

“This block contains unexpected or invalid content.” WordPress.org’s block error page says this usually comes from pasted or hand-edited HTML, or from a plugin or theme conflict. Try Attempt Block Recovery first. Convert to HTML and Convert to Classic Block will also make the error go away, but they change the block, so check the result. Our guide to editing WordPress in HTML explains when raw markup is worth the risk.

No Edit link at all. Your user role doesn’t allow it. Pages need the edit_pages capability. Authors can edit only their own posts, while Editors can edit everyone’s. Ask an administrator for the smallest role that covers the job.

Saved, but the live page still shows the old text

You are looking at a stored copy. The edit saved, but one of the cache layers between WordPress and your browser is still serving the old version. Clear them in this order, and check the page in a private window after each one:

1. Confirm the page actually shows Published, not Draft or Scheduled.
2. Clear your browser cache, or simply use a private window.
3. Purge your caching plugin.
4. Purge the host’s page cache from the hosting dashboard.
5. Purge the CDN (Cloudflare or your host’s own).
6. On builder pages, clear the builder’s cache or regenerate its CSS.

Clearing one layer can leave another still serving the old page. WP Engine’s cache documentation also notes that a full purge can slow the site for a short time while pages are cached again. Clear what you need, not everything, every time. Don’t keep re-editing the page while you wait. That adds revisions without changing anything. Our guide to pages that won’t update goes through each layer in detail.

If Google still shows the old wording, that is a separate, slower problem. Google’s recrawl documentation says crawling can take days to weeks, and asking repeatedly doesn’t speed it up. Request indexing once with URL Inspection in Search Console, then leave it.

How do you undo a text edit?

Use revisions. WordPress.org’s revisions documentation describes a record of each saved draft and published update. The comparison screen marks what was added, kept and removed. Open the Revisions link in the page settings, drag the slider to the version you want, click Restore, then check the live page.

There are two things to watch. Builders keep their own history, so the WordPress revision list may not include a builder edit. And if someone else edited the page after you, compare before restoring. Restoring your version would overwrite their newer work.

When should you stop and get help?

Stop when finding the text turns into experimenting on the live site. The warning signs keep repeating in support threads: switching themes to see what happens, turning off plugins while customers are shopping, editing a parent theme file, or copying a hard-coded sentence over the old one. Hand it off in these cases:

• You inherited the site and can’t tell which builder or theme generates the page.
• The text comes from the theme and there’s no setting for it.
• The JSON error survives the checklist above. That usually needs the host.
• The fix means changing a theme file, and there’s no child theme.

When you hand it off, give the page URL, the exact current sentence, the replacement, and whether it should go live or stay a draft. If you’d rather send that in chat than track down the template yourself, SiteSelf’s website edits page explains how the agent makes text changes on your existing site and reports what it checked. It refuses pages owned by Elementor, Divi or Beaver Builder and tells you why.

Frequently asked questions

A plugin updates overnight. In the morning the checkout buttons are in the wrong place, or the site shows a critical error. The obvious response is to switch off automatic updates and approve everything by hand from now on.

That works if you pick the right control, and if someone really does apply security fixes afterwards. WordPress has at least four separate update controls. Your host may run a fifth that ignores all of them. Most “I turned it off and it still updated” threads come from changing a setting that doesn’t govern the update the person wanted to stop. If an update has already failed or left the site half-updated, fix that first with our guide to failed WordPress updates. Then come back here and decide on a policy.

Which switch stops which update

Each control covers one kind of update. Pick the one that matches what you want to stop.

Start at the top of the table. The further down you go, the more you switch off, and the more likely you are to block a security fix you would have wanted.

How to stop one plugin or theme from updating itself

If one plugin broke something, turn off auto-updates for that plugin and leave the rest alone. WordPress.org’s documentation says these per-item controls need WordPress 5.5 or later. If you aren’t sure which version you run, check your WordPress version first.

1. Go to Plugins → Installed Plugins.
2. In the Automatic Updates column, click Disable auto-updates next to the plugin.
3. For a theme, go to Appearance → Themes, open the theme’s details and click Disable auto-updates. If you use a child theme, the parent theme is the one that receives updates.

To bulk-change plugins, tick several and pick Disable Auto-updates from the Bulk actions menu. On the command line, WP-CLI does the same with wp plugin auto-updates disable plugin-slug (available since WP-CLI 2.5.0) and wp theme auto-updates disable theme-slug.

The link column should now say “Enable auto-updates” for that item. One limit to keep in mind: this toggle doesn’t stop your host’s updater, and it doesn’t stop a security update WordPress.org decides to push.

How to stop major core releases but keep security fixes

Core has its own constant. Open wp-config.php and add one of these lines above the line that reads /* That's all, stop editing! */:

// Keep minor and security releases, skip major versions
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

// Or: turn off all automatic core updates
define( 'WP_AUTO_UPDATE_CORE', false );

WordPress’s Developer Handbook says this constant overrides the core auto-update setting on the Updates screen. It has no effect on plugins or themes. People mix this up often enough that a WordPress.org moderator had to explain in a 2025 support thread that WP_AUTO_UPDATE_CORE covers core only, while AUTOMATIC_UPDATER_DISABLED covers everything.

The 'minor' value is the setting most sites should use. Minor releases carry the security and maintenance fixes, and they are the ones you least want waiting on someone’s calendar.

Edit this file carefully. A missing semicolon or a stray quote takes the whole site down. Keep a copy of the original file so you can put it back in seconds. Editing wp-config.php needs file access through your host’s file manager, SFTP or SSH.

How to switch off all automatic updates, and what that costs

One line turns off the whole background updater:

define( 'AUTOMATIC_UPDATER_DISABLED', true );

WordPress’s handbook calls this “generally discouraged”, because minor and security updates are what keep a site secure. Treat it as a policy decision, not a fix. The site stays exactly as it is until someone logs in and updates it. If nobody owns that job, the site falls further behind every week.

To turn off plugin or theme auto-updates across the site but leave core alone, use filters. The handbook says filters belong in a must-use plugin, not in wp-config.php, where they can conflict with WP-CLI. Create wp-content/mu-plugins/update-policy.php:

<?php
/**
 * Plugin Name: Update policy
 * Description: Site update rules. Owner and date: write them here.
 */

// Stop auto-updates for one plugin only
add_filter( 'auto_update_plugin', function ( $update, $item ) {
    if ( isset( $item->slug ) && 'woocommerce' === $item->slug ) {
        return false;
    }
    return $update;
}, 10, 2 );

// Or stop all theme auto-updates
// add_filter( 'auto_update_theme', '__return_false' );

Know what returning false does. The handbook says it also blocks plugin and theme updates pushed by the WordPress.org security team. Don’t put update rules in your theme’s functions.php either. A theme switch or update can remove them without anyone noticing.

Why updates still happen after you switched them off

Usually something other than your setting is in charge. Check these in order.

A forced security update

WordPress.org can push an update for a critical vulnerability even when your toggles are off. In a 2024 WordPress.org thread, a site owner reported plugins updating with auto-updates disabled. The replies explained that security updates can be forced, and a moderator advised against overriding them when a flaw is being actively exploited. If the surprise update was a security release, the system did what it was built to do.

Your host runs its own updater

Managed hosts often update plugins from their own dashboard, outside WordPress. Some do it with a must-use plugin, which keeps running when you deactivate everything else. A GitHub issue logged in October 2026 shows Hostinger’s Smart Auto Updates MU plugin (v1.0.8) registering automatic_updater_disabled as true and auto_update_plugin as false. That is the opposite problem: settings switched off by the host, not by you.

In a 2023 WordPress.org case, Site Health warned that background updates weren’t working because the automatic_updater_disabled filter was enabled. The owner’s wp-config.php didn’t contain it. The source was a “Disable Auto Updates” MU plugin the host had installed. The owner waited days for it to be removed.

An update-management plugin

Plugins that manage updates keep their own rules. Running one next to a host updater gives you two policies that disagree. Choose one system and turn off the other.

To find which layer is in control:

1. Check the item’s toggle on the Plugins or Themes screen.
2. Look in your host’s control panel for anything labelled automatic or plugin updates.
3. Open wp-content/mu-plugins/, or Tools → Site Health → Info → Must Use Plugins.
4. Check for an update-management plugin in your plugin list.
5. Search wp-config.php for the two constants above. Old sites often still have them, and nobody remembers why.

If it’s still unclear, ask the host directly whether it updates plugins or core itself.

When updates aren’t running at all

Sometimes nobody switched anything off and updates still don’t happen. WordPress.org’s documentation says plugin and theme auto-updates rely on WP-Cron and run twice a day. If the scheduler or the file system is broken, no setting will help.

Open Tools → Site Health and read the Status tab. The WordPress.org Health Check handbook lists the checks that matter here: failed scheduled events, background updates and loopback requests. Then work through the causes:

• Cron. If DISABLE_WP_CRON is set in wp-config.php, a real server cron job has to replace it. Without one, scheduled updates never run.
• Permissions. If WordPress asks for FTP credentials, it can’t write files as the web server user. Ask the host to fix ownership. Don’t loosen permissions across the site.
• Disk space. A full disk stops updates from unpacking. Old backup archives are a common cause.
• A leftover .maintenance file. If the site says “Briefly unavailable for scheduled maintenance”, WordPress.org’s troubleshooting FAQ says to delete .maintenance from the WordPress root. Deleting it brings the site back. It doesn’t finish the update, so run the update again.

If an update broke the site, fix that one thing

Switching everything off hides the symptom and leaves the cause in place. Find the component first. WooCommerce’s self-service guide gives the standard routine: switch to a default theme, deactivate everything except WooCommerce and the extensions involved, then reactivate them one at a time.

Often the cause is narrow. In an October 2026 WordPress.org review, a site owner said a form plugin’s auto-update took their site down because the new version required PHP 8.3 and the server ran PHP 8.0. Turning off every update wouldn’t have fixed that. Upgrading PHP, or holding back that one plugin until the server could be upgraded, would have.

Roll back only the plugin that broke, and only until a fix ships. The Developer Handbook warns that older code can bring back security holes and cause database version problems. When a fixed version is out, turn that plugin’s auto-updates back on. Rolling back one plugin also keeps every order and edit made since your last backup. A full restore from backup throws those away.

Stores need extra care. WooCommerce’s update guide says some releases need a separate database update after the files update, and you can follow its progress under Scheduled Actions. The guide also says to back up the database and wp-content, test on staging, then check product pages, cart, checkout, payment, shipping, tax and email. It suggests a monthly cadence for most stores, with security fixes applied sooner.

The policy most practitioners settle on

WordPress.org threads and Reddit discussions keep landing on the same compromise:

• Keep minor core releases automatic, along with your security and backup plugins.
• Turn off auto-updates only for the plugins that can cost you money when they change: payments, checkout, page builders, heavily customised features.
• Update those by hand on a named day. Take a backup first, use staging if your host offers it, and update one at a time, never with “Update all”.
• After each update, load the homepage, submit a form and run a test checkout.
• Write down what is switched off, where, and who owns the manual updates.

WordPress.org has also started delaying some releases on its side. The Plugins Team’s phased release rollout, announced in August 2025, delays automatic updates by 24 hours for plugins that opt in. You can still update by hand during that window.

If nobody on your team wants to own the manual queue, SiteSelf handles plugin updates on request through chat, then reports what changed and what it checked.

Frequently asked questions

WordPress has no landing-page content type. A landing page is an ordinary Page with one job: get a visitor from an ad, an email or a post to take one action. You don’t need a special plugin, and you shouldn’t use the special feature some older tutorials describe. Elementor’s separate Landing Page feature is deprecated as of Elementor Pro 3.27.

The build is the easy part. Practitioners on Reddit and the WordPress.org forums keep naming the same hard parts: the copy, the scope, mobile behaviour, testing the form, and keeping the page in step with the offer once it’s live. This guide covers the whole job, from the goal to the launch checks. If you’re still choosing a tool, our guide to building a landing page in WordPress compares the block editor with page builders.

What should you decide before opening the editor?

Decide on one action and write it down in a single sentence. For example: “This page helps homeowners in our area request an interior painting quote.” If you can’t write that sentence, the page will try to do three things and none of them well.

Add three facts to the sentence. Where do visitors come from? What does the ad or email promise? What does your team need from the visitor to reply properly? Those answers decide the headline, the form fields and the slug.

Also decide what counts as a good result. A quote request from outside your service area is still a completed form, but it isn’t work. Track qualified enquiries next to raw submissions. Otherwise a page can look successful while it fills your inbox with leads you can’t serve.

What do you need before you start?

• Access: an Editor or Administrator account. To set the page as the homepage, change a template or install a form plugin, you need Administrator.
• Copy: a headline, three or four benefits, one or two pieces of real proof, and answers to the questions that hold buyers back. Write the copy before you build. Writing it during the build is what turns a three-hour page into a three-day page.
• Images: one hero photo of real work, sized for the web.
• A form tool your site already uses, if it has one.

How to create the landing page

1. Create the page. Go to Pages, then Add New. Give the page a title and set a short slug that uses the words from the ad, such as interior-painting-quote. If you change the slug after the campaign starts, every link already sent out breaks unless you add a redirect.
2. Choose the layout for this page only. This is the setting behind most “my menu disappeared” and “why is the header still there” questions, and it depends on your theme:
   • In a block theme, assign a custom template (Learn WordPress builds one without header navigation).
   • In a classic theme, pick the blank or full-width template if the theme provides one.
   • In Elementor, open Page Settings, then Page Layout. Canvas removes the header, footer and sidebars. Full Width keeps the header and footer. Elementor’s Single Page templates apply only to pages on the Default layout.
   Don’t edit a shared template to change one page. The WordPress Theme Handbook warns that a template change affects every page that uses it.
3. Write the hero to match the ad. An ad about interior painting should land on a headline about interior painting, not “Transform your space.” Say who the page is for, what they get and what to do next. Put the button beside that text. Use the same button wording (“Get a quote”) here and on the form’s submit button.
4. Add benefits, proof and objections. The Learn WordPress landing page lesson lists a hero with a call to action, benefits and social proof as the core sections. Place proof near the button, not three screens below it. A named review that mentions the type of job beats an anonymous compliment. Add an FAQ only for real hesitations, and put another button after it.
5. Build a short, accessible form. For every field, ask whether it changes what your team does next. If it doesn’t, cut it. Give every field a visible label. Placeholder text alone disappears as soon as someone types. The W3C’s guidance on labeling form controls says an explicit label’s for value must match the input’s id. Error messages should say what to fix. Our guide to adding a contact form in WordPress covers the plugin side.
6. Prepare the images. Compress the hero and check how it crops on a phone. Give informative images short alt text that says what they show. Give decorative images an empty alt="". Don’t leave the attribute out.
7. Publish, then decide about the homepage. A campaign page can live at its own URL. If it really should replace the homepage, go to Settings, then Reading, choose “A static page” and select it as the Homepage. The Homepage and the Posts page can’t be the same page. In a block theme, check Appearance, then Editor, then Templates, because a Front Page template there can override the Reading setting.

Selling one product? On a WooCommerce store, add the Single Product block to the page and choose the product. WooCommerce’s documentation says the block displays the product’s image, title, price and add-to-cart controls. A page that only looks like a product page can’t take payment. Keep Cart, Checkout and My Account as separate assigned pages. WooCommerce warns that combining them breaks redirects and payment gateways.

What does a correct result look like?

Test the live URL, not the editor preview, while logged out and on a real phone. Logged-in views often skip the cache, so you may see a version your visitors don’t. The page passes when:

• The first screen shows the offer and the button without zooming, and no popup or cookie banner covers them.
• The button scrolls to the form, and nothing sticky, such as a header or chat widget, hides the form after the jump.
• A test submission shows a confirmation and arrives in the right inbox. A success message on screen isn’t proof the email was delivered.
• Submitting with a required field left empty shows an error that says what to fix.
• The browser tab shows your real site name, not the default “My WordPress Blog” that practitioners on X keep finding on launch day.
• The exact URL from the ad, tracking parameters included, opens the page.

What to do if it did not work

Most broken landing pages are a setting, not a bug. Start with the symptom:

Don’t change the site-wide permalink structure to fix one page. WP Engine’s support docs warn that this can cause 404s across an established site. If the editor error is misleading, check the PHP error log as well as the browser console. In one WordPress.org support thread, “elementor is not defined” turned out to be the host’s 128 MB memory cap. When a fix needs server access or the cause stays hidden after these steps, ask your host or a developer.

Should you make a version for every city or keyword?

Only if each version has something real to offer that the others don’t. Google’s spam policies describe doorway abuse as pages that are substantially similar, target similar queries or locations, and funnel users to one destination. Swapping the city name in an otherwise identical page fits that description. One commenter on r/marketing gave a sensible rule: reuse a template when the use cases really are alike, and write separate pages when they differ.

Paid-traffic variants are different. Pages for an ad test are usually kept out of search anyway. If you run two near-copies, point a rel="canonical" at the main one or redirect the loser when the test ends.

How do you tell if the page is working?

Use your own numbers first. Unbounce reports a 6.6% median conversion rate from its Q4 2024 data across about 41,000 pages. That covers many industries and builders, and none of the data is specific to WordPress. A quote request, a sign-up and a purchase are different decisions, so a benchmark is context, not a target.

Record visits, form starts, submissions and qualified enquiries, split by device and by traffic source. Mobile falling while desktop holds points to layout, overlays or loading. People starting the form and not finishing points to fields or errors. Lots of traffic from one source with weak leads points to the ad’s promise. Change one thing at a time. On a low-traffic site, fix confirmed faults and clear confusing copy, and call untested tweaks guesses.

Then keep the page current. Practitioners on X describe the same decline: the demo gets imported and the text swapped, and then the price goes stale, nobody tests the form again, and the mobile layout slowly breaks as people add sections. Put a date in the calendar to re-test the form and check the offer. If you’d rather describe each change in chat and have it made and checked on your existing site, that’s what SiteSelf’s page and copy edits cover, though pages owned by Elementor, Divi or Beaver Builder are refused, with the reason.

Frequently asked questions