New Website SEO Checklist

Use this for: Every first-site launch.

Write a simple page list in a document or site editor. Include the real products, services, resources or information visitors need, plus the next action each page supports. Remove placeholder pages that have no useful answer yet. There is no required number of blog posts or minimum site size for a legitimate launch.

1. List the visitor’s important tasks.
2. Assign a useful page to each distinct need.
3. Complete or defer unfinished placeholders.

Use this for: Pages intended to attract search visitors.

Collect the words your audience uses, inspect relevant results and choose the page format that fits. Put one main topic beside each planned URL, with supporting questions beneath it. Closely related wording can belong on one page. Do not create several near-identical pages merely to cover singulars, plurals or reordered keywords.

1. Research the actual search task.
2. Choose the appropriate page type.
3. Map related questions to one suitable owner.

Use this for: New URLs not yet established.

In the page editor’s URL or permalink settings, use descriptive paths that fit the planned structure. Check for accidental duplicate paths and inconsistent conventions. Keep a simple map of each page’s final address for navigation and launch testing. A keyword in a URL is not a reason to later rename a working address without a transition plan.

1. Choose descriptive paths for new pages.
2. Check consistency and duplicates.
3. Use the final paths in the page map.

Use this for: Sites with multiple pages.

In the navigation editor, add clear labels for the main areas. Within useful page content, link relevant phrases to the next explanation or action. Follow the paths from the homepage to every priority page. A sitemap does not replace usable internal links, and there is no universal number of clicks or links to force into every site.

1. Create understandable main navigation.
2. Add relevant contextual links.
3. Follow the published or preview paths to important pages.

Use this for: Priority public pages with editable metadata.

Open the page’s SEO title and meta description fields. Name its main topic naturally in the title and summarize its specific value in the description. Avoid repeated generic titles such as Home or Services. Preview for readability; character targets are drafting aids rather than fixed Google requirements, and Google may display different wording.

1. Write distinct page-specific title and description text.
2. Keep claims consistent with the page.
3. Check the published title and description tag after launch.

Use this for: Every substantive launch page.

Use the editor’s heading styles to create a descriptive main heading and logical sections. Put the central answer or offering near the beginning, with necessary conditions nearby. Add real details such as coverage, inclusions, steps or limitations. Do not invent credentials, reviews or experience to make a new site look established.

1. Name the page subject in its main heading.
2. Organize necessary answers under descriptive sections.
3. Verify important facts and the intended next action.

Use this for: Pages using images.

Resize and compress new images for their actual display, then inspect clarity on small and large screens. Give informative images useful contextual alternative text in the media or image settings; mark decoration appropriately. Keep enough detail for diagrams to remain readable and respect the site’s supported format and rights requirements.

1. Prepare a suitably sized readable file.
2. Set contextual alt text or decorative treatment.
3. Check the uploaded image and layout.

Use this for: Sites with a development or review environment.

Use access control for a staging site containing private material. A public review copy may use noindex to stay out of search, but noindex is not password protection. Before launch, identify which restrictions must stay and which apply only to the temporary review. Keep staging addresses out of production links and sitemaps.

1. Choose the intended access level for the preview.
2. Apply appropriate protection or search exclusion.
3. List the settings that must change for production.

Use this for: Sites at their final public domain.

After the host and domain are configured, open the preferred HTTPS address in a normal browser. Confirm the certificate is valid and the page loads without a security warning. Check that intended alternate host/protocol versions reach the preferred location. If a warning appears, have the host fix it rather than asking visitors to bypass it.

1. Open the preferred HTTPS address.
2. Inspect any security or redirect problem.
3. Ask the host or developer to correct it.

Use this for: Public launch pages intended for indexing.

For a page intended for search, search its published source for noindex and inspect the document’s Response Headers in DevTools → Network for X-Robots-Tag. Check robots.txt and live URL Inspection when available. Confirm a successful response and visible main content. Remove staging restrictions only from intended public pages. A passing live test establishes current access, not a guarantee of indexing.

1. Confirm which public pages should appear in search.
2. Inspect their live response, content and restrictions.
3. Correct only unintended exclusions and retest.

Use this for: Sites using an XML sitemap.

Use the platform’s sitemap feature or maintained generator. Open the resulting XML and check that its page addresses use the final preferred domain and point to the intended canonical pages. Remove staging, redirected or deliberately excluded entries. A sitemap helps discovery; it is not a promise that every listed URL will be indexed.

1. Find or generate the sitemap.
2. Check representative entries and exclusions.
3. Publish the correct sitemap location.

Use this for: Owners setting up search monitoring.

Add the actual site in Search Console and choose a verification method supported by your ownership and platform. A domain property usually uses a DNS record; a URL-prefix property offers other supported methods. Follow the current verification instructions and confirm the property matches the live site. If you lack access, ask its owner rather than treating the setup as complete.

1. Choose the correct live-site property.
2. Complete a supported verification method.
3. Confirm you can open its reports.

Use this for: Verified properties after public launch.

In the verified property, open Sitemaps and submit the sitemap’s actual location. Check processing errors and inspect an important public URL with URL Inspection. A processed sitemap and a successful live test answer different questions; neither guarantees inclusion in search. Avoid repeatedly requesting indexing as a substitute for fixing a real problem.

1. Submit the correct sitemap.
2. Review any reported processing issue.
3. Inspect a representative priority URL.

Use this for: Sites with public visitor journeys.

Open the live site on a phone or narrow browser view. Read the main content, use the menu and follow the primary action. Check for clipped diagrams, covered controls and awkward scrolling. Use an approved test or staging mode for forms and purchases so the test is safe and identifiable.

1. Read and navigate the live mobile page.
2. Try the main action safely.
3. Fix the specific layout or interaction problem.

Use this for: New sites ready for performance testing.

Run representative live pages in PageSpeed Insights and use the site yourself. Separate laboratory diagnostics from real-user data. A new website may not have enough field data for an assessment. Investigate a diagnosed large image, slow resource or shifting element, then retest under comparable conditions rather than chasing a score without understanding the cause.

1. Test important page templates.
2. Identify a relevant diagnosed bottleneck.
3. Fix and compare like-for-like results.

Use this for: Sites with an approved analytics implementation.

If analytics is part of the launch, confirm its approved implementation and test the intended lead, purchase or resource action using a safe test. In the platform’s realtime/debug view, check that the expected event appears without unwanted duplication, considering consent and filtering settings. Search clicks and analytics events measure different things.

1. Test the real intended action safely.
2. Check its expected event where analytics exists.
3. Resolve a functional or recording mismatch.

Use this for: New sites after launch.

After launch, check Page indexing and Performance as data becomes available. Inspect important exclusions and compare like-for-like queries and pages when enough history exists. A new site can take time to be crawled and assessed; there is no guaranteed day for indexing or rankings. Set a sustainable review cadence based on actual changes and needs.

1. Review important indexing statuses.
2. Investigate concrete access or content issues.
3. Build a comparable baseline as real data arrives.