A website builder can handle much of the technical setup, but it cannot decide whether every page is clear, crawlable, useful, and ready for visitors. Use this website builder SEO checklist before publishing, after a redesign, and whenever you add an important landing page. It covers the settings and quality checks that help search engines understand your site and help people use it.
Overview
SEO before launch is less about finding a single “boost” and more about removing avoidable problems. Start with the site structure, then review each page’s content, search settings, technical signals, and user experience. Complete the checklist on the final published preview or staging version where possible; settings can behave differently in an editor than they do on the live site.
First, define the main purpose of the website and the action you want visitors to take. A small business site may prioritize calls, inquiries, bookings, or visits to a physical location. A creator site may prioritize subscriptions, portfolio views, or downloads. This purpose should guide the navigation, page order, calls to action, and page titles.
| Area | Before publishing, confirm |
|---|---|
| Structure | Important pages are linked from navigation or other relevant pages, with no unnecessary duplicate paths. |
| Page metadata | Each indexable page has a distinct title and useful meta description. |
| Content | One clear main topic, descriptive headings, readable copy, and a useful next step. |
| Technical access | The intended domain uses HTTPS, important pages are indexable, and the sitemap and robots settings are deliberate. |
| Measurement | Analytics, Search Console verification, and any consent controls are tested. |
If your launch also involves a domain or hosting change, pair this checklist with the business website launch cloud hosting checklist. For DNS records and SSL troubleshooting, see the domain-to-cloud-hosting guide.
Checklist by scenario
For a new website
- Plan the page set. List the home page, core service or product pages, about page, contact page, legal or policy pages, and any supporting resources. Keep the navigation focused. A page should have a reason to exist and a clear relationship to the rest of the site.
- Choose a logical URL for every important page. Use short, readable paths that describe the subject. Avoid unnecessary dates, random IDs, repeated words, and changing a URL after promotion has begun. If a URL must change, plan a permanent redirect from the old address.
- Write page-specific titles and descriptions. The title should identify the page’s subject and, where useful, the business or site name. The description should explain what a visitor will find or do. Do not copy one title and description across the entire site.
- Check headings and page copy. Give each page one clear main heading that matches its purpose. Use lower-level headings to organize sections, not merely to create visual styling. Make sure the opening copy tells visitors what the page offers without requiring them to interpret vague slogans.
- Review images. Resize or compress images appropriately, use descriptive file names when practical, and add alternative text that communicates the image’s purpose. Decorative images can generally use empty alternative text if the builder supports it. Do not place essential instructions only inside an image.
- Configure the site-wide essentials. Set the preferred domain, HTTPS behavior, favicon, language where available, social sharing image, and contact details. Remove placeholder text, sample pages, test forms, and unused template content.
For a redesign or migration
- Export or record the current URLs, page titles, important backlinks, and pages receiving search traffic before changing the site.
- Map each old URL to the most relevant new URL. Use redirects when a page has moved; do not send every old address to the home page unless that is genuinely the closest destination.
- Preserve valuable content where it remains accurate, but improve thin, duplicated, or outdated pages rather than carrying them forward automatically.
- Test internal links, forms, images, downloads, canonical tags, redirects, and mobile layouts on the new version before switching the domain.
- After launch, inspect the highest-value old URLs and new URLs, then monitor indexing and traffic for unexpected changes.
The website migration to cloud hosting guide provides a complementary process for a hosting move. Keep a backup and a tested recovery path as well; the website backup and disaster recovery plan covers restore testing and recovery planning.
For a new landing page or campaign
- Give the page a specific search and conversion purpose instead of duplicating an existing service page.
- Use a stable, readable URL and link to it from a relevant existing page if it should be discoverable beyond the campaign.
- Decide whether the page should be indexed. A private, temporary, or substantially duplicated campaign page may need different settings than an evergreen resource.
- Confirm the page has a title, description, main heading, relevant copy, accessible form labels, a clear call to action, and a working confirmation path.
What to double-check
Indexing, canonical tags, sitemap, and robots settings
Use the builder’s visibility controls deliberately. Confirm that the home page and important public pages are not marked noindex, while private areas, test pages, and duplicate variants are not exposed unintentionally. Review the generated XML sitemap and confirm it contains the canonical, publicly accessible URLs you want search engines to discover. A robots file should support your intended crawl behavior; do not use it as a substitute for access control or privacy protection.
Canonical tags should point to the preferred version of a page when duplicate or parameterized URLs are possible. Check that the canonical uses the correct protocol and domain, resolves successfully, and does not point to an unrelated page. If the builder does not expose canonical controls, test how it generates them and avoid creating unnecessary duplicate URLs.
Structured data and business details
Add structured data only when it accurately describes visible page content and when the builder or an approved integration supports it. Commonly relevant types may include organization, local business, breadcrumbs, article, product, or event markup, depending on the site. Do not add fields simply to make a page appear more complete, and validate the result after publishing. Structured data can help systems interpret content, but it does not replace useful page copy or guarantee a special search result.
Mobile usability, speed, and accessibility
Review every key template on a real phone or a reliable mobile preview. Check horizontal scrolling, tap target spacing, readable text, menus, sticky elements, forms, dialogs, and image cropping. Test the page on a slower connection when possible. Use your builder’s performance tools and current Search Console or PageSpeed reporting to review Core Web Vitals and other loading signals; use the thresholds shown by those current tools rather than relying on an old checklist.
Also check keyboard navigation, visible focus, color contrast, form labels, link text, captions where needed, and meaningful alternative text. These checks improve usability and can reveal problems that a purely visual desktop review misses.
Analytics, Search Console, and consent
Install analytics only after confirming the measurement plan: identify the pages, forms, downloads, or actions that matter and test whether events are recorded once rather than multiple times. Verify the site in Google Search Console or the relevant webmaster platform, submit the sitemap if appropriate, and inspect representative URLs after launch.
If your site uses analytics, advertising, personalization, or other nonessential tracking, configure the consent experience according to the jurisdictions and tools relevant to your audience. Make the choices understandable, provide the required controls, and test that tags behave as intended before collecting data.
Common mistakes
- Publishing template text. Placeholder headlines, generic descriptions, and dummy contact details damage trust and make page intent unclear.
- Using the same metadata everywhere. Repeated titles and descriptions make it harder to distinguish pages and may produce poor search snippets.
- Blocking the entire site by accident. Check noindex controls, password protection, staging settings, and robots rules immediately after launch.
- Redirecting without a map. A redesign that changes URLs without redirects can break bookmarks, links, and established page access.
- Ignoring the canonical domain. Decide whether visitors should use the www or non-www version and ensure alternate versions resolve consistently.
- Treating a builder’s default settings as a complete SEO strategy. Defaults may be useful, but they do not replace page-level titles, helpful content, internal links, image text, testing, and measurement.
- Checking only the home page. Search engines and visitors may enter through a service page, article, product page, or campaign URL. Test representative pages from every important template.
When to revisit
Run this checklist before the first publication, before each major redesign, and whenever a new template, domain, hosting setup, analytics tool, or consent tool is introduced. Recheck it before seasonal campaigns and important landing-page releases. After launch, perform a focused review once the site has had time to be crawled and visited, looking for indexing, redirect, form, and performance issues.
Plan a broader review at least twice a year, and sooner when search-engine guidance, builder capabilities, structured-data recommendations, Core Web Vitals reporting, privacy requirements, or your measurement workflow changes. Keep a simple change log with the date, pages affected, settings changed, and tests completed.
For ongoing operations, use the cloud site maintenance checklist and quarterly calendar. Before publishing, save this article as a launch task list: crawl the final site, inspect key URLs, test mobile and forms, verify analytics and consent behavior, confirm sitemap and redirects, then document what was checked. A site is ready when its intended pages are accessible, understandable, measurable, and usable—not merely when the builder reports that publishing is complete.