WordPress gives your team a way to publish and update content. SEO still depends on the pages you create, the decisions made during development and the way the site is maintained after launch. An SEO plugin can support editing and technical settings, but it cannot make an unclear offer useful or guarantee search visibility.
Use this guide when planning a new WordPress site, reviewing an existing one or preparing a redesign.
Start with the launch decisions
Work through the checklist in three stages:
Before development: agree which pages matter, keep a record of existing URLs and name the owners of content and accounts.
Before launch: test indexing settings, metadata, redirects, the sitemap and the complete enquiry journey on the production setup.
After launch: confirm the public site works, hand over the editing and recovery instructions, and review search visibility alongside suitable enquiries.
Keep a short record of the URL tested, the result, the person who checked it and any open action. This makes the checklist useful for an agency reviewing a developer’s work as well as a business taking ownership of its website.
Give every important page a clear job
Start with the pages that explain your main services, products or customer questions. A visitor should be able to understand who the offer is for, what is included, why the information is credible and how to take the next step.
Give each page one main purpose. A service page, project example and advice article can support each other without repeating the same copy. Avoid creating many near-identical pages with only a place name or keyword changed.
Write a descriptive page title, one clear main heading and section headings that help people scan. The words should match the page a visitor actually receives. A title that promises something the page does not explain may attract the wrong visit and weaken trust.
Set URLs and visibility before launch
Choose a readable permalink structure early. WordPress describes permalinks as the permanent addresses for posts, pages and archives, so changing them later needs a migration plan. Review the official WordPress permalink guidance before an established site is restructured.
During development, a staging website should not replace the real site in search results. Before launch, ask the developer to check:
whether the production site allows search engines to index it;
whether staging or preview copies remain excluded;
whether the preferred HTTPS and domain version is used consistently;
whether each important page points to its own intended canonical URL;
whether the XML sitemap contains only pages intended for search;
whether robots rules still allow search engines to load the files needed to render the pages.
WordPress’s Reading setting asks search engines not to index the site; it does not restrict visitor access. Use access controls for private staging. On a publicly accessible page, Google must be able to crawl it to read noindex; blocking the URL in robots.txt can prevent that. Check the production page’s final output before launch.
The WordPress SEO documentation provides a starting overview. The final checks still need to reflect the theme, plugins, hosting and content used by the actual website.
Decide what the SEO plugin is responsible for
An SEO plugin can make it easier to edit titles and descriptions, create an XML sitemap, set canonical URLs or add supported structured data. Confirm which plugin is responsible for each function. Two plugins or a theme generating the same metadata can create conflicting output.
Treat plugin scores as editing prompts. A green indicator does not prove that a page answers a useful question, deserves to rank or will generate enquiries. Read the finished page as a customer would.
Record the important plugin settings and licence owner. If a plugin is replaced, check that metadata, redirects, sitemaps and structured data continue to work instead of assuming another plugin uses the same defaults.
Preserve useful pages during a redesign or migration
Before changing the design or content system, create an inventory of the current URLs. Use the existing sitemap, analytics, Search Console, incoming links and business knowledge to identify pages that people and search engines already use.
For each old URL, decide whether to:
keep it at the same address;
improve it without changing the address;
combine it with a genuinely relevant page;
redirect it permanently to a suitable replacement;
remove it and return a real not-found response.
Do not send every removed page to the homepage. Google recommends a direct permanent server-side redirect when a page has moved, along with an accurate old-to-new URL map. Its site-migration guidance also recommends updating internal links, canonicals and the sitemap to the new addresses.
Keep the redirect map with the project handover. Test the important old addresses after launch and avoid redirect chains where one old address passes through several others before reaching the final page.
Make the templates useful on a phone
Review real service pages, articles, forms and WooCommerce journeys on a phone. Check that the main information appears in a sensible order, text remains readable, navigation works without precision tapping and the next action is clear.
Use images that support the explanation. Add alternative text when an image communicates information; leave decorative images out of the reading experience. Compress and size images appropriately so visitors do not download files much larger than the space where they appear.
Performance is part of usability. Google’s Core Web Vitals guidance focuses on loading, responsiveness and visual stability using real-world experience data. Start with heavy images, third-party scripts, fonts, layout shifts and slow hosting, then measure again. Do not remove necessary content merely to chase a perfect laboratory score.
Build a useful internal-link structure
Every page you care about should be reachable through normal links from another relevant page. Main service pages may appear in navigation, while related articles and project examples can be linked within the explanation they support.
Use concise anchor text that describes the destination. “WordPress development service” gives a reader more context than several repeated “click here” links.
Avoid adding a large block of unrelated links to every page. Link when the destination helps the reader answer the next question, compare an option or take an action.
Review archive and duplicate pages
WordPress can create category, tag, author, date, search and media-related pages. Some may help visitors browse; others may repeat excerpts or create thin collections.
List the archive types the site produces and decide which have a real audience. Do not apply the same answer to every WordPress site. A publication may need useful category archives, while a small service website may have no reason to expose dozens of tag pages.
Ask the developer to check canonical and indexing settings for archives, attachment pages, filtered shop pages and any duplicated print or tracking URLs. Test the rendered output rather than relying only on an admin-screen setting.
Keep themes, plugins and access maintainable
Agree who owns the hosting, domain, theme and plugin licences. Record which person is responsible for updates, backups, security monitoring and recovery. Give each person their own account with only the access they need.
Before a major update, confirm that a usable backup exists and that someone knows how to restore it. Test important updates away from the live checkout or enquiry journey when the site’s setup allows it.
Remove software that is no longer needed after checking whether it supplies a visible feature, data, redirect or integration. A plugin count by itself is not a diagnosis; the condition, purpose and behaviour of each component matter.
Use a practical pre-launch checklist
Before publishing a new or redesigned WordPress site, verify:
the production site is indexable and the staging site is not;
important titles, descriptions, headings and canonical URLs are correct;
the final sitemap opens and lists the intended canonical pages;
navigation and contextual links reach the pages that matter;
old URLs redirect directly to relevant replacements;
forms, email delivery, bookings, payments and consent choices work;
analytics and Search Console use the intended property;
mobile layouts, keyboard access and visible focus states work;
missing pages return a real 404 response;
the domain, hosting, repository, licences and recovery access have named owners.
A checklist does not replace testing. It gives the launch team a shared record of what was checked and who owns anything still open.
Agree one labelled enquiry test with the inbox owner. Record form acceptance, email receipt and any analytics event separately, respecting the consent choice. A success message does not confirm email delivery, and a test is not a qualified lead. Keep personal details out of analytics and test submissions separate from genuine enquiries.
Hand over a site the owner can maintain
At handoff, the client should be able to update the site and know who to contact when something needs attention. Provide:
invitations to the client-owned domain, hosting, WordPress and reporting accounts;
a walkthrough of editing a real page, including images, links and metadata;
the final redirect map and a record of launch tests, including form email delivery;
the licence owner and renewal responsibility for paid themes and plugins;
the backup and restore instructions, with an agreed maintenance owner;
known issues, accepted limitations and the scope of any ongoing support.
Use provider invitations rather than copying passwords into a shared document. An agency can adapt our development handover checklist to record the client handoff and unresolved decisions.
Review the site after launch
Recheck the main pages, forms and redirects from the public domain. Confirm that analytics records genuine visits and that successful enquiries are measured at the point the website actually accepts them.
Submit the correct sitemap in Search Console and inspect a few priority pages. Read the stored indexing report separately from the live test: a successful live fetch does not confirm indexing or rankings. Investigate the recorded exclusion reason before acting. Monitor coverage and queries; repeatedly requesting the same URL does not speed crawling.
Review which landing pages receive relevant impressions, visits and enquiries. Improve pages when the data and customer questions reveal a gap. Do not publish new articles merely to meet a schedule.
Finally, agree a maintenance rhythm for content, software and business information. A useful WordPress site is an operating responsibility, not a one-time launch file.
If you are planning a new build, WooCommerce store or migration, explore our WordPress and WooCommerce development service and delivery process. Bring the current website, the pages that matter and the problems your team encounters most often.