On-Page SEO Checklist for New Websites

A new website's SEO foundations should be checked before launch, but a checklist is most useful when it becomes part of the publishing workflow. The site may look complete in a design preview while public pages still carry staging noindex directives, missing canonical values, generic titles or a broken contact form. These defects are easier to prevent when each page has a clear purpose and a documented acceptance test. The goal is not a perfect score from one plugin. It is a collection of useful pages with accurate information, a coherent navigation structure and technical behaviour that can be verified on the actual production website.

Build a list of intended public pages

Before adding metadata, identify which pages need to exist and what each should help visitors accomplish. A service business may need an overview, distinct service explanations, a genuine coverage page, contact details and supporting guides. A product business may need categories, individual products, delivery information and a workable checkout. These pages answer different questions; do not create a separate URL for every synonym merely to increase the site's size.

Create a simple launch inventory with intended canonical URL, page type, audience, main task, owner and whether search indexing is appropriate. This helps the team spot repeated drafts, placeholder pages and paths that should not be public. When two intended articles have substantially the same purpose, decide whether a single complete resource would be clearer. Keeping information architecture deliberate avoids expensive consolidation after launch.

Review the inventory with the people responsible for operations. A writer should not invent a branch address, guarantee or product compatibility detail just because the design template contains a field. Launch content needs approved, truthful facts before it needs decorative optimisation.

Check title elements and semantic main headings

Every important page should have an accurate HTML title and a visible heading that tells readers what they have opened. They need not be identical strings, but they should promise the same subject. A category page titled simply 'Products' may be too generic when several product categories exist, while a title containing every possible keyword variation is difficult to read. Distinctive wording should follow the real page content.

Inspect several page types together because shared templates can generate repeated titles or H1 elements. One correction in the template may fix a whole group. Use genuine heading elements for structure and styling for appearance. A visually large paragraph is not necessarily a semantic heading. The W3C heading guidance explains why logical structure supports accessible navigation.

Check the published output rather than the editor field. A page builder may save a heading that the production template never renders, or a shared component may insert an unexpected second topic heading. Record the exact URL and whether the final content matches the promise.

Write useful descriptions without promising exact snippets

The meta description can give Google a candidate summary of the page, but Google may select a different excerpt for a particular query. Write a concise, truthful description for important pages, indicating the real answer or offer. Avoid keyword lists, unsupported prices and generic descriptions repeated across every URL. Where a large catalogue uses programmatic generation, test the variables and fallbacks before enabling it site-wide.

A description is not a direct guarantee of ranking improvement or a fixed text string that every searcher will see. Google explains its snippet selection in Search Central documentation. For launch QA, the immediate test is whether the correct meta element appears in public HTML and reflects the actual page. Treat later search presentation as a separate observation.

Check the title, description and opening paragraph together. A description promising same-day service must not survive when the business has not authorised that availability. Make factual updates part of publishing rather than leaving metadata outside the review process.

Confirm the primary URL and HTTPS behaviour

Choose the intended hostname and use consistent internal links. Confirm that the site serves HTTPS with a valid certificate for the relevant hostnames. Where HTTP or an alternate hostname should redirect, test that it reaches the correct equivalent destination rather than an unrelated homepage. Broken or circular redirects can prevent visitors from reaching important content and complicate discovery.

Keep URLs stable and descriptive where possible. Do not change them repeatedly to insert more search terms. If old addresses exist from a previous site, map them to genuinely relevant successors and test representative cases. A successful HTTP response at the final URL is necessary, but also read the content to ensure the destination answers the original link's promise.

Document who manages DNS, certificates and domain renewals. An SEO launch checklist cannot compensate for a domain that expires or a certificate that fails without a responsible owner.

Remove staging restrictions deliberately

One of the most consequential launch errors is leaving a site configured to discourage indexing. A staging noindex instruction might have been appropriate during development, but it can block the intended search presence after release. Inspect the final public HTML meta robots directives and relevant HTTP headers. Do not assume a CMS checkbox tells the whole story.

Robots rules and noindex instructions perform different jobs. Blocking crawling can prevent a search engine from seeing instructions on the page itself. A site may also have private account paths requiring genuine authentication rather than a search directive. Decide which URLs should be public and eligible for indexing, then test their actual behaviour with current Google guidance.

Use Search Console URL Inspection where authorised to investigate important pages, while recognising that eligibility does not guarantee indexing. A sitemap submission helps discovery but does not force inclusion. Keep a documented list of intentionally excluded pages so routine audits do not misclassify them as defects.

Validate canonical signals and near-duplicate pages

Canonical declarations can help indicate preferred URL representatives when similar or duplicate pages exist. Check that each intended public page has coherent canonical and redirect behaviour. A template that points every service page to the homepage can seriously conflict with the site's intended architecture. Detect such errors before launch through representative tests across page types.

Do not use canonical tags to collapse genuinely different customer tasks. A definition and a detailed troubleshooting procedure may both deserve distinct pages. Conversely, tracking parameters and unnecessary URL variants may generate duplicates that should be handled consistently. Google's canonical URL documentation explains the signals and their limitations.

After deployment, inspect the public HTML, internal links and eventual redirects together. One database field is not proof the final page sends the correct canonical signal.

Connect important destinations through ordinary links

An XML sitemap is helpful but cannot replace sensible navigation. A visitor should find the principal service, product or guide through relevant menus, categories or contextual links. The illustration above shows a simplified network of connected documents. Your actual site will be more complex, but each important public page still needs an understandable route from a relevant source.

Use descriptive anchor text rather than unrelated exact-match keyword strings. Test both source and destination, especially when a page has moved. A navigation link that opens a 404 or redirects to irrelevant material can make a new site look unfinished. Check orphan candidates with a crawl, then confirm whether each should truly be public before adding links.

Test mobile menus and keyboard navigation. A link available only through a hover interaction may be hard to use on touch devices, and a scripted control may not behave like an ordinary anchor for crawling. Google provides link best practices to support reliable discovery.

Check images, copyright and accessible descriptions

Images should contribute useful information, show actual products or clarify a process. Use suitable source dimensions and formats rather than uploading enormous originals to every page. Give meaningful images appropriate alternative text and reserve their layout space so they do not cause unexpected movement. Images below the first viewport may be suitable for lazy loading, while the main hero or LCP candidate should not automatically be deferred.

Check copyright separately from technical performance. An online image is not automatically free to reproduce. Preserve creator attribution, original file URL and licence conditions. A generic illustration should not be described as proof of this site's specific performance or an actual customer case. If the image licence cannot be established, replace the asset or hold that element rather than fabricating permission.

Verify public delivery after the deployment. A URL saved in the CMS may fail through caching, hotlinking rules or a path change. Inspect alt text, caption and source links on the live page, including narrow mobile layouts.

Test page performance and responsive behaviour

Large media, blocking scripts and third-party widgets can delay important content. Use appropriate diagnostics to investigate actual bottlenecks rather than treating every plugin warning as equivalent. Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift capture different performance concerns. A good lab score does not prove that a customer can submit a form.

Test representative widths such as 320, 375 and 768 pixels, along with real devices where possible. Check long headings, tables, forms, menus and interactive components. A comparison table may need scrolling inside its own labelled region rather than forcing the entire page sideways. Confirm focus states and meaningful form errors. Privacy banners and floating widgets should not obstruct essential controls.

Review shared templates first. One change to a product gallery or menu may affect hundreds of URLs. Test representative pages after any such release to avoid fixing a speed issue by accidentally removing required functionality.

Install measurement without manufacturing success

Set up appropriate Search Console access and analytics according to the business's privacy requirements. Document who owns the properties and which events are meaningful. A search impression, click, website pageview, form start and qualified enquiry are different observations. Do not mark every button click as a completed commercial action.

Test event collection on representative journeys. Verify that invalid form attempts do not trigger successful submission counts and that test data is excluded from customer reporting as appropriate. A new site may have limited early observations, making percentage changes volatile. Record the source and date range rather than inventing a pre-launch performance baseline.

Google's Search Console Performance documentation explains search-side metrics but does not guarantee a return from any specific launch change. Keep measurement findings separate from direct functional acceptance.

Repeat the checks for every later page

A launch checklist should become part of the content creation process. Add its key fields to the CMS workflow: page purpose, accurate title, approved description, relevant links, image rights, intended canonical and public test. Assign ownership so each new guide or service page receives the same review instead of relying on somebody remembering the launch exercise months later.

Run a fresh representative audit after redesigns, plugin upgrades and content imports. Those changes can reintroduce defaults that were previously fixed. Keep a change log of what was updated and publicly tested. Where frontend access fails or an internal editor note appears publicly, mark that as a distinct unresolved deployment issue rather than declaring 12/12 success from a saved database record.

The strongest new-site SEO checklist supports a maintainable publishing system. It helps a small team launch accurate pages, keep them accessible and improve them with genuine evidence. Start with the site's most important visitor task and verify the complete public route before spending time polishing minor tool preferences. The Google SEO Starter Guide gives further context, but indexing and rankings are never guaranteed by ticking a fixed list of boxes.