Preparing a WordPress site for launch

Preparing a WordPress site for launch means much more than checking whether the homepage looks finished and then pointing the domain at the new server.

A production launch affects several independent systems at once:

• DNS;
• HTTPS;
• WordPress URLs;
• search-engine indexing;
• robots directives;
• XML sitemaps;
• redirects;
• email delivery;
• forms;
• analytics;
• caching;
• performance;
• user permissions;
• scheduled tasks;
• backups;
• security;
• external integrations.

A site can therefore look perfect in a browser while still being completely unprepared for production.

The most dangerous launch problems are often not visual at all.

A beautiful site can launch with:

noindex enabled

broken contact forms

staging URLs in the database

missing redirects

SMTP disabled

analytics pointing to staging

HTTP assets inside HTTPS pages

an expired TLS certificate

public staging copies

no recoverable backup

and everybody involved can still initially congratulate themselves because the hero section has a tasteful animation.

This guide provides a practical WordPress launch checklist covering staging, backups, URL migration, HTTPS, indexing, robots.txt, XML sitemaps, redirects, email, forms, users, security, caching, performance, media, analytics, scheduled events and post-launch monitoring.

First decide what kind of WordPress launch you are performing

Not every launch carries the same risk.

There are three common scenarios.

Scenario 1: completely new website

For example:

staging.example.com

becomes

example.com

and:

example.com

did not previously contain an established website.

The main concerns are:

• correct production configuration;
• search-engine visibility;
• HTTPS;
• email;
• forms;
• performance;
• analytics;
• security.

Scenario 2: redesign on the same domain with unchanged URLs

For example:

Old site:
https://example.com/services/

New site:
https://example.com/services/

The domain and important URL paths remain stable.

This reduces migration complexity, but you still need to verify:

• content parity;
• metadata;
• canonical tags;
• internal links;
• structured data;
• forms;
• tracking;
• indexation.

Scenario 3: migration with URL changes

For example:

Old:
https://old-example.com/services/web-design/

New:
https://example.com/web-design/

or:

Old:
http://example.com/?page_id=42

New:
https://example.com/services/

This requires a migration plan, not merely a launch checklist.

URL-changing launches need explicit mapping

The official Google Search Central site migration documentation recommends preparing the new site, mapping old URLs to new destinations, implementing permanent redirects and monitoring the move after launch.

For the deeper WordPress workflow, see How to migrate WordPress URLs safely.

Build a launch checklist before launch day

Do not rely on memory.

A launch affects too many independent systems for:

I'm pretty sure we checked that

to qualify as deployment engineering.

Assign ownership to each item

For example:

DNS:
Developer

SEO redirects:
SEO specialist

Analytics:
Marketing

Forms:
Account manager

Email:
Developer

Final content:
Client

Backup:
Developer

Use three statuses

A simple checklist can use:

Not checked
Verified
Issue found

This is much clearer than a document filled with ambiguous checkmarks somebody added three weeks earlier.

Do the final review on production-like infrastructure

A website that works on:

localhost

has not proven that it works with:

• the production PHP version;
• the production database;
• the production web server;
• the production CDN;
• the production caching layer;
• the production mail server;
• the production domain.

Use staging properly

A staging environment should resemble production closely enough to expose real deployment problems without being the public production site.

See WordPress staging site best practices.

Staging should not be publicly indexable

A staging copy can create:

• duplicate content;
• duplicate canonical signals;
• wrong URLs in search results;
• test pages appearing publicly;
• unfinished copy being crawled.

But robots.txt alone is not access control

This:

User-agent: *
Disallow: /

asks compliant crawlers not to crawl the site.

It does not prevent somebody with the URL from opening it.

See Robots.txt vs. real access control.

Use actual staging protection where appropriate

Possible layers include:

• HTTP authentication;
• VPN restrictions;
• IP restrictions;
• application-level password gates.

TheOneWP Site Password Protection can provide a shared password gate around public WordPress content while a site is still being reviewed.

Do not confuse staging protection with maintenance mode

These solve different problems.

STAGING PROTECTION

Purpose:
Keep a development environment
away from normal public access


MAINTENANCE MODE

Purpose:
Temporarily replace or interrupt
an already-live site during work

For the live-site workflow, see WordPress maintenance mode best practices.

Create a complete backup before launch

Before changing production, create a backup of the current production state.

If you are replacing an existing site, this means backing up the site that visitors are using immediately before the deployment.

A recoverable launch backup should include both files and database

At minimum:

Database
wp-content
uploads
themes
plugins
configuration required for restore

A database backup alone cannot restore deleted files

Likewise, copying:

wp-content/

without the database does not restore:

• posts;
• pages;
• settings;
• users;
• taxonomy relationships;
• plugin configuration.

Test the restore process before you need it

A backup file existing somewhere does not prove:

the website can be restored.

The backup strategy is complete only when recovery has been verified.

Have a rollback plan

Write down:

What triggers rollback?

Who decides?

Which backup is restored?

How is DNS handled?

How are new production changes
during the failed launch preserved?

Rollback criteria should be objective

For example:

Rollback if:

checkout cannot complete
critical forms fail
site returns widespread 500 errors
authentication is broken
database migration corrupts content

Not every small visual bug requires rollback

A slightly misaligned icon can often be fixed after launch.

A broken ecommerce checkout cannot.

Backup Manager can support launch and migration workflows

TheOneWP Backup Manager can create complete, database-only or file-only backups and supports restoration and migration workflows.

For migrations, its implementation also uses serialized-data-aware URL replacement rather than naive string replacement.

Serialized WordPress data makes URL replacement dangerous

Some WordPress values are stored in PHP serialized structures.

A serialized string contains its length.

For example:

s:20:"https://old.test";

If a migration changes the text without updating the serialized length, the stored structure can become invalid.

See Why serialized data breaks naive WordPress migrations.

Confirm the final production domain before replacing URLs

Determine the canonical site form:

https://example.com

or:

https://www.example.com

Do not leave multiple canonical hostnames unresolved

You should normally decide one canonical variant and redirect alternatives consistently.

For example:

http://example.com
http://www.example.com
https://www.example.com

→

https://example.com

Check WordPress Address and Site Address

In WordPress these are commonly represented by:

home
siteurl

They may also be overridden through:

WP_HOME
WP_SITEURL

in configuration.

Do not change only what appears in Settings

If constants override database values, editing:

Settings
→ General

may not be the actual source of truth.

Search the database for staging URLs

After migration, look for references to:

staging.example.com

dev.example.com

localhost

127.0.0.1

Common places staging URLs survive include

• page-builder data;
• custom fields;
• theme options;
• widgets;
• menus;
• CSS backgrounds;
• serialized plugin settings;
• email templates;
• canonical configuration.

Check hard-coded development URLs in theme files

Database replacement will not fix:

background-image:
url("https://staging.example.com/image.jpg");

inside a hard-coded stylesheet or template.

Use relative or WordPress-generated URLs where appropriate

Hard-coded environment-specific domains make migrations unnecessarily fragile.

Configure HTTPS before public launch

A production site should normally be served consistently over:

https://

Check the TLS certificate

Verify:

• the certificate is valid;
• the hostname matches;
• the certificate chain is valid;
• renewal is configured;
• www/non-www variants are covered where required.

Redirect HTTP to HTTPS

Requests to:

http://example.com/page/

should normally redirect to:

https://example.com/page/

Avoid redirect chains

Poor:

http://www.example.com/page
↓
https://www.example.com/page
↓
https://example.com/page
↓
https://example.com/page/

Better:

http://www.example.com/page
↓
https://example.com/page/

Google recommends keeping redirect chains low and redirecting directly to the final destination where possible.

Check for mixed content

An HTTPS page can still load resources using:

http://

Examples include:

• images;
• fonts;
• scripts;
• stylesheets;
• iframes.

Mixed content can cause browser blocking

A page may therefore appear correct during development but lose:

• fonts;
• JavaScript functionality;
• embedded content;
• background images.

once HTTPS rules are enforced.

Test HTTPS from a clean browser session

Developer sessions can hide problems because of:

• cached redirects;
• cached assets;
• logged-in state;
• browser extensions.

Check search-engine visibility before launch

WordPress provides:

Settings
→ Reading
→ Search engine visibility

Development sites often discourage indexing

This is sensible during staging.

The disaster occurs when production launches and:

Discourage search engines
from indexing this site

remains enabled for the next six months.

WordPress Site Health now checks this directly

Use:

Tools
→ Site Health

before launch.

The official WordPress Site Health documentation describes Site Health as a built-in diagnostic system for configuration, security, updates and performance.

On a public production site, indexing should normally be enabled

Current WordPress Site Health reports a recommended issue when:

blog_public = 0

and the site appears configured to discourage search engines.

But WordPress’s visibility checkbox is not guaranteed exclusion

The wording itself says:

Discourage search engines

not:

Cryptographically prevent all indexing.

Use appropriate controls during development

For private staging:

real access restriction
+
appropriate noindex behavior

is safer than relying on one crawler preference.

Check robots meta directives

Search the rendered production HTML for:

<meta name="robots"
      content="noindex">

on pages that should become indexable.

Check X-Robots-Tag headers too

Noindex behavior can also come from HTTP headers:

X-Robots-Tag: noindex

which will not appear in page HTML.

Check robots.txt

Open:

https://example.com/robots.txt

and verify that development rules did not survive.

A classic launch failure looks like this

User-agent: *
Disallow: /

on the newly public site.

Do not blindly copy staging robots.txt into production

Google explicitly recommends preparing the production robots configuration before a site migration and removing development-only crawl restrictions when the move begins.

Make sure important CSS and JavaScript are crawlable

Search engines render pages.

Blocking essential frontend resources can make pages harder to understand correctly.

Check the XML sitemap

Modern WordPress includes native XML sitemap functionality, while SEO plugins and other tools may provide their own implementation.

For the fundamentals, see What is an XML sitemap and why does it matter?.

A production sitemap should contain production URLs

Not:

https://staging.example.com/page-a/
https://staging.example.com/page-b/

Check that the sitemap excludes inappropriate content

Depending on site architecture, you may not want sitemap entries for:

• internal content types;
• thin archives;
• private content;
• utility pages;
• temporary landing pages.

XML Sitemap can centralize sitemap output

TheOneWP XML Sitemap can generate sitemap output as part of the site’s SEO configuration.

Submit or verify the sitemap after launch

For established sites, use the appropriate search-engine webmaster tools to verify the production sitemap after migration.

Do not submit a staging sitemap

This sounds absurd until someone does it.

Someone always does it.

Check canonical URLs

A production page should normally canonicalize to its intended production URL.

For example:

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

Do not leave staging canonical tags

This:

Production page:
https://example.com/services/

Canonical:
https://staging.example.com/services/

sends exactly the wrong signal.

Check canonical consistency across important templates

Test:

• homepage;
• pages;
• posts;
• custom post types;
• archives;
• pagination;
• taxonomy archives.

Review title tags and meta descriptions

Launch is the final moment to catch:

Home | Just another WordPress site

before Google does.

Verify important pages individually

At minimum review:

• homepage;
• main service/product pages;
• contact page;
• major category pages;
• important landing pages.

SEO Meta can centralize metadata

TheOneWP SEO Meta can manage page-level SEO metadata where the project uses that module.

Check Open Graph and social previews

Verify that important pages provide the intended:

• title;
• description;
• social image;
• URL.

Staging social URLs are easy to overlook

Especially when Open Graph output comes from cached plugin data or custom fields.

Create an old-to-new URL map for redesigns and migrations

If the old website had:

/services/web-design/
/services/seo/
/about-us/
/contact-us/

and the new site uses:

/web-design/
/seo/
/about/
/contact/

create an explicit mapping:

/services/web-design/
→ /web-design/

/services/seo/
→ /seo/

/about-us/
→ /about/

/contact-us/
→ /contact/

Use permanent redirects for permanent URL moves

For most permanent migrations this means:

301

or another correct permanent redirect such as 308 depending on implementation.

See 301 vs. 302 vs. 410: which redirect to use?.

Do not redirect every old URL to the homepage

This destroys useful mapping information and creates a poor experience.

For example:

/old-pricing/
→ /

is rarely better than redirecting to the closest relevant replacement.

Removed content may require a different status

If a resource has been intentionally removed and has no replacement, an HTTP status such as:

410 Gone

may be more semantically appropriate than an irrelevant redirect.

Redirect Manager can maintain migration rules

TheOneWP Redirect Manager can manage redirect rules without requiring every mapping to live inside web-server configuration.

Test redirects before declaring the migration complete

Check:

• status code;
• destination;
• redirect chains;
• loops;
• query-string behavior;
• case differences where relevant.

Use a crawler for large migrations

Manually testing:

8 URLs

is realistic.

Manually testing:

8,000 URLs

is how errors become institutional tradition.

Check internal links

Production pages should link directly to final production destinations.

Do not rely on redirects to repair internal links forever

Poor:

Internal link
→ old URL
→ 301
→ new URL

Better:

Internal link
→ new URL

Search for staging-domain links

Inspect:

• navigation menus;
• footer links;
• buttons;
• content links;
• images;
• download links;
• custom HTML.

Check broken links

Pay particular attention to:

• old landing pages;
• downloadable PDFs;
• menu items;
• footer legal pages;
• image links;
• custom post type archives.

Test the 404 page

Visit an intentionally nonexistent URL:

/this-page-definitely-does-not-exist/

The page must actually return 404

A pretty error page returning:

200 OK

is a soft-404 problem.

Understand important HTTP status codes

For launch work, know the practical difference between:

200
301
302
307
308
404
410
500
503

See HTTP status codes for WordPress sites, explained.

Check forms in production

A contact form working on staging does not prove production works.

Test every important form end to end

This includes:

• contact forms;
• lead forms;
• newsletter subscriptions;
• quote requests;
• registration forms;
• checkout flows;
• password reset;
• account activation.

Do not merely check that the success message appears

A successful frontend AJAX response proves:

the form handler responded.

It does not prove:

the email arrived.

Verify the destination mailbox

Check:

• Inbox;
• Spam;
• sender identity;
• reply-to address;
• subject;
• message formatting.

Test WordPress transactional email

Production email may include:

• password resets;
• new-user messages;
• form notifications;
• order confirmations;
• administrative alerts.

WordPress mail success does not guarantee inbox delivery

For the full distinction, see WordPress SMTP vs. PHP mail, explained and Why WordPress emails go to spam.

Configure authenticated SMTP where appropriate

TheOneWP Mail Manager can configure SMTP host, port, encryption, authentication and sender details, then send an actual test email.

Check SPF, DKIM and DMARC

If the domain sends email, verify the DNS authentication strategy.

See SPF, DKIM and DMARC, explained.

Do not wait for the first customer password reset to discover email is broken

Production is a poor testing department.

Check all integrations

Production credentials often differ from staging credentials.

Review integrations such as:

• payment gateways;
• CRM systems;
• newsletter providers;
• analytics;
• captcha services;
• maps;
• social APIs;
• webhooks;
• external search;
• object storage;
• CDNs.

Switch payment systems out of test mode

Conversely, verify that test transactions cannot accidentally affect production customers.

Check API keys against the production hostname

Some services restrict keys by:

• domain;
• IP address;
• callback URL;
• redirect URI.

Review webhook URLs

A production checkout calling:

https://staging.example.com/webhook/

can create wonderfully invisible failures.

Check analytics before launch

Verify that the production site has the correct tracking configuration.

Do not send staging traffic into production analytics

Likewise, do not launch production while still using:

staging measurement IDs

Verify real page-view events

Use the analytics provider’s realtime/debug tooling where available.

Check conversion events

Test:

• form submissions;
• purchases;
• downloads;
• phone-click events;
• lead conversions.

Consent systems can affect tracking

If analytics depends on consent, verify both:

before consent

after consent

states.

Review users before production

Staging environments often accumulate:

developer accounts
client-test accounts
old agency accounts
temporary administrators

Remove unnecessary users

Every administrator account expands the attack surface.

Review roles and capabilities

Use least privilege.

A person who only edits articles normally does not need:

Administrator

simply because assigning the correct role required thirty additional seconds.

See How to audit user roles on a WordPress site.

Review dormant accounts

See Auditing dormant WordPress user accounts.

Check whether public registration is intentionally enabled

Go to the relevant WordPress settings and confirm whether:

Anyone can register

matches the site’s actual business requirements.

Review the default new-user role

Never leave an unexpectedly privileged default role on a production site.

Harden authentication before launch

A production site immediately becomes a target for automated login attempts.

See A WordPress login hardening checklist.

Enable two-factor authentication for privileged users where appropriate

TheOneWP Two-Factor Authentication can add another authentication factor for protected accounts.

Use unique passwords

Do not launch with credentials such as:

admin
password123

because humans have apparently spent decades proving automated attackers deserve easy victories.

Remove unused themes and plugins

Inactive software can still represent:

• attack surface;
• maintenance burden;
• disk usage;
• future confusion.

Keep one sensible fallback theme if required

But a production installation rarely needs:

nine abandoned themes

left from experiments.

Update WordPress, plugins and themes carefully

Do not blindly perform every available update five minutes before launch.

The correct workflow is:

Backup
↓
Update on staging
↓
Test
↓
Deploy verified versions

Site Health can reveal obvious configuration problems

Check:

Tools
→ Site Health
→ Status

and:

Tools
→ Site Health
→ Info

WordPress Site Health can surface issues involving updates, PHP, REST availability, scheduled events, search visibility and other environment details.

Review PHP version and extensions

Production should use a supported PHP version compatible with:

• WordPress Core;
• theme;
• plugins;
• custom code.

Do not assume staging and production use the same PHP version

Differences such as:

staging:
PHP 8.3

production:
PHP 8.1

can produce bugs that never appeared during development.

Enable production-appropriate debugging settings

Do not expose PHP errors publicly.

For example, production generally should not dump:

database credentials
file paths
stack traces
plugin code

into visitor-facing pages.

Logging and display are different

You may want:

error logging:
enabled

error display:
disabled

depending on operational requirements.

Check caching after migration

Clear all relevant cache layers after production deployment.

Possible layers include

• browser cache;
• WordPress page cache;
• object cache;
• server cache;
• reverse proxy;
• CDN cache;
• image CDN;
• DNS cache.

Do not assume one Purge Cache button clears everything

A modern WordPress deployment can have several independent caches.

Stale CSS is a classic launch problem

You deploy:

style.css

but visitors continue receiving the previous version.

Use asset versioning where appropriate

WordPress’s enqueue APIs support version parameters.

See wp_enqueue_scripts explained.

Check image cache behavior after replacing launch assets

If launch day includes last-minute replacement of logos or hero images, cached resources can survive.

See WordPress image cache-busting, explained.

Run performance tests before public traffic arrives

Performance should be tested on:

production-like infrastructure

with production caching and CDN behavior.

Test representative pages

At minimum:

• homepage;
• largest landing page;
• blog article;
• product page;
• archive page;
• checkout where applicable.

Look beyond one performance score

Review:

• page weight;
• requests;
• server response time;
• large images;
• render-blocking resources;
• third-party scripts;
• layout shift;
• fonts;
• JavaScript execution.

Third-party scripts deserve special scrutiny

Chat widgets, analytics, video embeds and advertising scripts can become some of the heaviest resources on a page.

See Why third-party embeds slow down WordPress.

Check web fonts

Fonts can introduce:

• extra requests;
• privacy concerns;
• render delay;
• layout shift.

See Self-hosting Google Fonts in WordPress and Why web fonts cause layout shift and how to avoid it.

Optimize production images

Check whether hero images and other large media are appropriately:

• resized;
• compressed;
• formatted;
• served responsively.

TheOneWP Image Optimizer can assist with Media Library image optimization and modern formats.

Do not upload enormous originals simply because the CMS accepts them

If the largest frontend use is:

1600 × 900

serving a:

9000 × 6000
20 MB

source image is rarely an achievement worth preserving.

Check generated image sizes

TheOneWP Image Sizes List can show which image dimensions are registered by Core, themes and plugins.

Test responsive behavior thoroughly

Do not test only:

desktop
mobile

as if the universe contains exactly two browser widths.

Check intermediate widths

Especially:

1440
1280
1024
900
768
600
430
390
360
320

or widths relevant to the site’s design system.

Test real interactions

Verify:

• mobile menu;
• dropdowns;
• accordions;
• modals;
• forms;
• carousels;
• tabs;
• sticky headers;
• off-canvas panels.

Test keyboard navigation

Check whether users can navigate important interactive elements without a mouse.

Check visible focus states

A custom design should not remove:

outline

without providing another visible focus indicator.

Review headings

Headings should reflect content structure rather than merely visual size.

Check:

H1
H2
H3

hierarchy on representative pages.

Check image alternative text

Important content images should have appropriate alternative text.

Decorative images may need empty alt attributes rather than meaningless descriptions.

Test color contrast

Pay attention to:

• text;
• buttons;
• links;
• placeholder text;
• disabled states;
• form errors.

Check form validation messages

Errors should tell users what is wrong and how to fix it.

Do not rely only on color

A red border around an invalid field is not sufficient information by itself.

Check menus and navigation

Verify every main menu item.

Look for common launch leftovers

Page #
Lorem ipsum
Coming soon
Test page
Sample Page
Hello world!
Menu Item

Review the footer

Footers often contain forgotten development details such as:

• old phone numbers;
• wrong email addresses;
• staging links;
• wrong copyright year;
• placeholder social profiles.

Check legal pages

Confirm required pages are present and linked appropriately for the site’s jurisdiction and business model.

This may include:

• privacy policy;
• cookie information;
• terms;
• returns;
• shipping;
• company information.

Do not copy legal text blindly from another site

Website launch is not improved by publishing a privacy policy describing another company’s data processing.

Check favicon and site icon

Verify:

• browser tab;
• bookmarks;
• mobile shortcuts;
• admin context where applicable.

Check the site title and tagline

Remove defaults such as:

Just another WordPress site

Check timezone

WordPress timezone settings affect:

• scheduled posts;
• events;
• cron tasks;
• date displays;
• logs.

Prefer an actual city timezone where appropriate

For example:

Europe/Rome

rather than manually setting a static UTC offset when daylight-saving changes matter.

Check WP-Cron and scheduled events

Scheduled functionality may include:

• scheduled posts;
• email sequences;
• cleanup jobs;
• backup schedules;
• plugin synchronization;
• commerce tasks.

Site Health can detect scheduled-event issues

Do not discover after launch that:

scheduled posts never publish

because loopback requests or cron processing are broken.

Check WordPress REST API behavior

Modern WordPress and many plugins depend on REST endpoints.

Do not disable REST blindly

Doing so can break:

• Block Editor functionality;
• plugins;
• mobile integrations;
• external applications.

Check browser console errors

Open representative pages and inspect for:

JavaScript errors
failed resource requests
CORS errors
mixed-content warnings

Check server logs too

Frontend silence does not prove backend health.

Review production logs for:

• PHP warnings;
• fatal errors;
• database errors;
• 500 responses;
• failed cron requests.

Check frontend logged out

Developers often spend weeks viewing the site while authenticated.

Logged-in users can receive different output

Differences can involve:

• cache bypass;
• admin bar;
• permissions;
• personalized content;
• maintenance bypass;
• plugin behavior.

Always test as a normal visitor

Use:

private browser window
or
clean browser profile

Test authenticated user roles separately

Where relevant, test:

Administrator
Editor
Author
Subscriber
Customer
custom roles

Review redirects after login and logout

If the site uses custom account flows, verify users land in sensible places.

Redirect After Login and Redirect After Logout can control these workflows where appropriate.

Check ecommerce separately

An ecommerce launch needs a deeper transactional test.

Test at least one complete purchase

Verify:

• product;
• cart;
• coupon where used;
• checkout;
• payment;
• order creation;
• customer email;
• admin email;
• inventory;
• tax;
• shipping.

Test payment failure too

A checkout should handle unsuccessful transactions cleanly.

Check currency and tax settings

A site can be technically functional while charging the wrong amount, which customers tend to notice with refreshing speed.

Check production database cleanup carefully

Before launch you may want to remove:

• test posts;
• test orders;
• temporary users;
• spam;
• transients;
• old revisions;
• development logs.

Do not run aggressive database cleanup without backup

A launch is not the ideal moment to discover which supposedly unused table belonged to the ecommerce plugin.

DB Optimizer can handle targeted cleanup

TheOneWP DB Optimizer can clean categories of unnecessary WordPress database records where appropriate.

Inspect suspicious database state before deleting it

TheOneWP Database Manager can assist with database inspection and administration.

Remove test content from the Media Library where safe

Development often creates:

test.jpg
test-1.jpg
screenshot.png
logo-old.png
demo.pdf

But do not delete media based on filenames alone

Check usage and attachment relationships first.

For larger cleanup workflows, see Organizing a large WordPress media library.

Review comments and discussion settings

If the website does not use comments, do not accidentally launch with comments enabled across content merely because WordPress once assumed blogs were the center of civilization.

Review pingbacks and trackbacks

Disable unnecessary legacy discussion behavior where the project does not require it.

Check XML-RPC requirements

Some websites do not need XML-RPC, while certain integrations still do.

Decide based on actual functionality rather than disabling it by ritual.

Check file permissions

Production file and directory permissions should be restrictive enough for security while still allowing WordPress operations that legitimately require write access.

Do not use 777 as a universal debugging philosophy

If permissions were temporarily loosened during deployment, correct them before production.

Check sensitive files

Ensure files such as:

wp-config.php
backup archives
database dumps
debug logs
environment files

are not publicly downloadable.

Remove migration archives when no longer needed

A:

site-backup.zip

inside a public web directory can contain essentially the entire website.

Check backups are stored appropriately

A backup existing only on the same server as the production website does not protect against every failure scenario.

External backup storage improves resilience

Depending on operational needs, keep recoverable copies outside the production server.

Check DNS before the launch window

If a domain migration is involved, understand:

• A/AAAA records;
• CNAME records;
• MX records;
• TXT records;
• TTL;
• CDN proxy state.

Lower TTL in advance where appropriate

If you know a DNS change is coming, reducing TTL sufficiently before the move can shorten the period during which old resolver caches remain valid.

Do not accidentally modify email DNS records

A website migration usually does not require destroying:

MX
SPF
DKIM
DMARC

records.

Changing nameservers can affect far more than the website

Before replacing nameservers, inventory all DNS records.

Take a DNS backup

Record the current zone before making major DNS changes.

Confirm production after DNS changes

Do not assume:

it works on my computer

means every resolver now points to the correct destination.

Plan the launch window

For an established site, launch during a lower-traffic period where practical.

Google also recommends considering lower-traffic periods for site migrations.

But do not launch at a time when nobody can respond

This:

Friday
23:55
everyone goes home
production deploy

is technically a low-traffic window and operationally a small act of hostility.

Have the responsible people available after launch

Depending on the project:

• developer;
• hosting contact;
• SEO specialist;
• client decision-maker;
• commerce administrator.

Freeze content briefly during final migration if necessary

If production remains editable while staging is being copied over, you can lose:

• orders;
• comments;
• form submissions;
• new users;
• content edits.

Define the source of truth

During the launch window decide whether:

old production

or

staging/new production

owns new content.

Dynamic sites need migration planning

An ecommerce or membership site cannot always be copied like a static brochure site.

You may need separate treatment for:

• orders;
• customers;
• memberships;
• comments;
• form entries.

Perform a final pre-launch crawl

Crawl the site before launch and record issues involving:

• 404s;
• redirect chains;
• missing titles;
• duplicate titles;
• noindex;
• canonical URLs;
• broken internal links;
• HTTP links;
• staging URLs.

Perform another crawl after launch

The second crawl verifies that production behavior matches the staging audit.

Compare the two

Unexpected differences may reveal:

• migration failures;
• configuration differences;
• missing redirects;
• cache problems;
• production-only plugin behavior.

Check Search Console after launch

For public sites, monitor:

• indexing;
• sitemaps;
• crawl errors;
• redirect behavior;
• canonical selection;
• traffic changes.

Temporary fluctuations can happen after URL migrations

Google notes that significant site moves can cause temporary ranking fluctuations while URLs are recrawled and signals are transferred.

Do not immediately remove old redirects

Google recommends keeping migration redirects for a long period, generally at least a year.

From a user perspective, keeping useful redirects longer can often make sense.

Monitor 404 logs after launch

Real users and crawlers quickly discover URLs your migration spreadsheet forgot.

Redirect logs can expose missing mappings

See Reading a redirect access log.

Do not automatically redirect every observed 404

Some requests are:

• bots;
• malware scans;
• typos;
• irrelevant nonexistent resources.

Only create redirects where a meaningful old or mistaken URL has a valid replacement.

Check uptime immediately after DNS cutover

Monitor:

• homepage;
• critical application pages;
• checkout;
• login;
• forms.

Check server resource usage

Production traffic can expose:

• CPU limits;
• memory pressure;
• database contention;
• PHP worker exhaustion;
• cache misconfiguration.

Migration can temporarily increase crawl activity

Google advises ensuring server capacity is sufficient because old URLs may redirect to new URLs while the new site is being crawled directly.

Do not celebrate immediately after DNS resolves

A successful DNS lookup proves:

DNS works.

It does not prove:

SEO works
forms work
email works
checkout works
cron works
canonical tags work

Run a post-launch smoke test

Immediately after production becomes public, test:

Homepage
Primary navigation
Contact form
Login
Search
Critical landing page
404
Sitemap
robots.txt
HTTPS
One transactional email
Analytics
Critical integration

Then run a deeper validation

Once the initial deployment is stable, inspect:

• all templates;
• redirect mapping;
• structured data;
• accessibility;
• performance;
• server logs;
• Search Console;
• scheduled tasks.

Keep a record of production configuration

Document important details such as:

• hosting environment;
• PHP version;
• cache layers;
• CDN;
• SMTP provider;
• DNS provider;
• backup destination;
• analytics identifiers;
• deployment process.

Do not store passwords in the launch checklist

Documentation should describe:

where credentials are managed

rather than becoming another plaintext password database.

A practical WordPress pre-launch checklist

• Create and verify a full production backup.
• Document the rollback procedure.
• Confirm the final canonical domain.
• Confirm WordPress Home and Site URLs.
• Replace staging URLs safely.
• Search for remaining development URLs.
• Verify HTTPS and TLS certificates.
• Redirect HTTP to HTTPS.
• Avoid unnecessary redirect chains.
• Check mixed content.
• Verify production search-engine visibility.
• Remove unintended noindex directives.
• Check X-Robots-Tag headers.
• Verify robots.txt.
• Verify the XML sitemap.
• Check sitemap URLs use the production hostname.
• Check canonical URLs.
• Review SEO titles and descriptions.
• Review social metadata.
• Create old-to-new URL mappings.
• Implement appropriate permanent redirects.
• Test redirects.
• Check internal links.
• Check downloads and media links.
• Verify the 404 page returns HTTP 404.
• Test every important form.
• Verify form email delivery.
• Test password reset email.
• Configure SMTP where appropriate.
• Verify SPF, DKIM and DMARC where relevant.
• Switch integrations to production credentials.
• Verify payment gateways.
• Verify webhooks and callback URLs.
• Verify analytics.
• Verify conversion tracking.
• Review user accounts.
• Remove temporary administrators.
• Audit roles and capabilities.
• Review public registration settings.
• Enable authentication protections.
• Review installed plugins and themes.
• Remove unnecessary software.
• Check WordPress Site Health.
• Verify PHP compatibility.
• Verify production debug configuration.
• Clear all relevant cache layers.
• Check asset cache busting.
• Test page performance.
• Optimize oversized images.
• Test responsive layouts.
• Test keyboard navigation.
• Review headings and alt text.
• Check footer and navigation links.
• Remove placeholder content.
• Review legal and privacy pages.
• Check favicon and site identity.
• Verify timezone.
• Check scheduled events and WP-Cron.
• Check REST API functionality.
• Check browser console errors.
• Check server/PHP logs.
• Test while logged out.
• Test relevant user roles.
• Clean development content carefully.
• Remove publicly accessible backup files.
• Review file permissions.
• Verify DNS records.
• Back up the DNS zone before major changes.
• Plan a sensible launch window.
• Define any content freeze.
• Run a pre-launch crawl.
• Run a post-launch crawl.
• Monitor Search Console.
• Monitor 404s and redirect logs.
• Monitor uptime and server resources.
• Run an immediate production smoke test.

A simplified launch-day sequence

1. Freeze changes where required
        ↓
2. Final production backup
        ↓
3. Deploy files/database
        ↓
4. Replace environment URLs safely
        ↓
5. Apply production configuration
        ↓
6. Activate HTTPS
        ↓
7. Apply redirects
        ↓
8. Clear caches
        ↓
9. Remove staging-only index blocks
        ↓
10. Verify sitemap / robots / canonical
        ↓
11. Test forms and email
        ↓
12. Test critical site flows
        ↓
13. Switch DNS if required
        ↓
14. Production smoke test
        ↓
15. Crawl and monitor

A launch decision tree

Is this replacing an existing website?
│
├── No
│   └── Focus on production readiness,
│       indexation and integrations
│
└── Yes
    │
    └── Are URLs changing?
        │
        ├── No
        │   └── Preserve metadata,
        │       content and indexation
        │
        └── Yes
            └── Build URL map,
                redirects, sitemap,
                canonical and migration
                monitoring

A rollback decision tree

Problem detected
│
├── Cosmetic / isolated?
│   └── Fix forward
│
└── Critical?
    │
    ├── Data corruption
    ├── checkout failure
    ├── widespread 500 errors
    ├── authentication failure
    └── major business flow broken
        │
        └── Consider rollback
            using verified backup

A search visibility decision tree

Environment?
│
├── Staging/private
│   └── Restrict access
│       + prevent indexing
│
└── Public production
    │
    └── Should page be indexed?
        │
        ├── Yes
        │   └── Remove development
        │       noindex/blocking
        │
        └── No
            └── Apply deliberate
                page-level strategy

Common WordPress launch mistakes

Leaving “Discourage search engines” enabled

The site launches successfully and then spends months politely asking search engines to ignore it.

Leaving noindex on production templates

A particularly effective way to make the redesign difficult to discover.

Copying staging robots.txt to production

Especially:

Disallow: /

Leaving staging canonical URLs

Production pages then identify the staging copy as preferred.

Replacing URLs with naive SQL string replacement

Serialized WordPress data can be corrupted.

Forgetting old-to-new redirects

Existing inbound links and indexed URLs begin returning 404.

Redirecting every old page to the homepage

That is not a migration strategy.

Testing forms only visually

A success message is not proof of email delivery.

Leaving SMTP in staging configuration

Production notifications go nowhere useful.

Leaving payment gateways in test mode

Excellent for simulated revenue.

Leaving analytics attached to staging

Marketing receives beautifully accurate data about the wrong environment.

Keeping temporary administrator accounts

Accounts created for development should not automatically become permanent production identities.

Launching with debug output enabled

Visitors receive an unexpected tour of filesystem paths and PHP internals.

Skipping the backup because the migration looks simple

Migrations have an astonishing ability to become interesting immediately after somebody says that.

Backing up only the database

Deleted uploads remain deleted.

Backing up without knowing how to restore

A backup nobody can recover from is an archival hobby.

Ignoring redirect chains

Several technically correct redirects can still produce a poor final path.

Testing only while logged in

Cached visitor output can behave differently.

Testing only desktop and mobile extremes

Tablet widths exist, despite repeated efforts by responsive CSS to pretend otherwise.

Ignoring WP-Cron

Everything seems fine until scheduled operations quietly stop happening.

Leaving backup ZIP files publicly reachable

A convenient downloadable copy of the website is rarely the launch feature anybody requested.

Changing DNS without preserving MX/TXT records

The website launches while company email stops. Team-building follows.

Launching late Friday with nobody available

The server has no respect for weekends.

Related WordPress launch and migration guides

For the wider launch, migration, SEO and production-readiness cluster, continue with:

• WordPress staging site best practices
• WordPress maintenance mode best practices
• Robots.txt vs. real access control
• How to migrate WordPress URLs safely
• Why serialized data breaks naive WordPress migrations
• 301 vs. 302 vs. 410: which redirect to use?
• HTTP status codes for WordPress sites, explained
• Reading a redirect access log
• What is an XML sitemap and why does it matter?
• WordPress SMTP vs. PHP mail, explained
• Why WordPress emails go to spam
• A WordPress login hardening checklist
• How to audit user roles on a WordPress site
• Backup Manager
• Site Password Protection
• Redirect Manager
• XML Sitemap
• Mail Manager
• Two-Factor Authentication

Final thoughts

Preparing a WordPress site for launch is ultimately an exercise in removing assumptions.

Do not assume the production domain replaced every staging URL.

Search for them.

Do not assume Google can index the site.

Check robots directives, WordPress search visibility, canonical URLs and the sitemap.

Do not assume old URLs will somehow resolve themselves.

Create a mapping and test the redirects.

Do not assume email works because a form displays a green confirmation box.

Read the actual message in the destination mailbox.

Do not assume backups work because a ZIP exists.

Verify recovery.

Do not assume staging and production behave identically.

Run production smoke tests as a logged-out visitor.

A good launch process therefore has four phases:

Prepare
↓
Verify
↓
Deploy
↓
Monitor

TheOneWP Backup Manager can provide the recovery and migration layer, Site Password Protection can help keep pre-launch environments gated, Redirect Manager can manage URL transitions, XML Sitemap can support production discovery and Mail Manager can verify outgoing SMTP configuration before the site depends on it.

The objective is not to make launch day exciting.

A technically successful launch should actually be rather boring: DNS resolves, HTTPS works, URLs redirect correctly, forms deliver, search engines see what they should see, caches clear, backups exist and visitors notice nothing except that the new website is online.

If the launch becomes cinematic, somebody probably skipped the checklist.