Technical SEO Checklist for a New Business Website

A new website can look finished long before it is ready for search engines.

The design may be approved.

Forms may work.

Content may be published.

The domain may even be live.

But technical problems underneath the surface can still make important pages difficult to crawl, duplicate URLs compete with each other, prevent pages from being indexed, or give search engines incomplete information about the site.

That is why technical SEO should be part of the website build—not a task added months after launch.

This checklist covers the foundations a new business website should have before search visibility becomes a growth priority.

1. Make Sure Important Pages Can Actually Be Indexed

Start with the most basic question:

Can search engines access and index the pages you want customers to find?

Development and staging environments often use noindex while a site is being built.

That is sensible.

The problem occurs when those directives survive the production launch.

Review important pages such as:

• homepage
• service pages
• product or solution pages
• category pages
• case studies
• contact pages
• important Insights or educational content

and confirm that pages intended for organic search are not accidentally sending noindex.

At the same time, not every URL needs to be indexed.

Administrative pages, internal search results, account areas and other low-value utility pages may reasonably be excluded.

The objective is not:

“Index everything.”

It is:

“Make intentional decisions about what belongs in search.”

2. Understand the Difference Between robots.txt and noindex

These two controls solve different problems.

robots.txt primarily controls whether a crawler is allowed to request particular URLs.

noindex tells compatible search engines that a page should not appear in their index.

That difference matters.

If Google cannot crawl a page because it is blocked by robots.txt, it may never see a noindex directive placed inside that page.

So do not treat:

Disallow: /something/

as a reliable replacement for:

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

Use crawling controls and indexing controls for the jobs they were designed to perform.

3. Give Every Important Page a Clear Canonical URL

Modern websites can accidentally expose the same or very similar content through multiple URLs.

For example:

/service
/service/
/service?source=campaign

Or an e-commerce system may create multiple paths to the same product.

Canonicalization helps search engines understand which URL represents the preferred version.

For a normal standalone business page, that will often mean a self-referencing canonical:

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

Canonical URLs should also be consistent with:

• internal links
• sitemap URLs
• redirects
• HTTPS usage
• preferred hostname

Avoid telling search engines five different stories about which URL is authoritative.

A canonical tag works best as part of a consistent URL strategy, not as a patch for uncontrolled URL generation.

4. Create an XML Sitemap

A new business website should have an XML sitemap containing the canonical URLs that are intended for search.

Typical entries may include:

• primary pages
• services
• products
• categories
• case studies
• published articles

Do not fill the sitemap with:

• redirects
• 404 pages
• noindex pages
• admin URLs
• duplicate URLs
• temporary environments

A sitemap helps search engines discover and understand the URLs you consider important.

It does not guarantee that every URL will be indexed.

The content still needs to be crawlable, useful and technically accessible.

5. Use Real, Crawlable Internal Links

Search engines should be able to reach important pages through the site's navigation and content—not only through the sitemap.

Use standard links with meaningful destinations.

Your website architecture might look something like:

Home → Services → E-commerce Development

or:

Insights → SEO & Performance → Technical SEO Article

Important pages should not exist as isolated URLs that can only be discovered through an XML file.

Internal links also help establish relationships between related content.

For example, technical SEO and website performance overlap significantly, so connecting those topics naturally helps both users and search engines navigate the site.

6. Use One Clear Primary Heading

Every important page should have a clear primary topic.

For most conventional business pages, that means one obvious <h1> representing the page's main subject, followed by logical <h2> and <h3> sections.

The goal is not to create headings for search-engine manipulation.

Heading structure should make the content easier to understand.

For example:

H1: E-commerce Development

    H2: Shopify Development

    H2: WooCommerce Development

    H2: Custom E-commerce

        H3: ERP Integrations

        H3: Customer-Specific Pricing

That structure is useful for humans first.

It also gives machines a clearer representation of how the information is organized.

7. Write Unique Page Titles

Every important indexable page should have a descriptive <title>.

Avoid a site where dozens of pages simply say:

Creafter

or:

Services | Creafter

when the page has a much more specific purpose.

A better pattern might be:

E-commerce Development Services | Creafter

The title should accurately describe the page without turning into a list of repeated keywords.

Also remember that the HTML <title> is an important input—not an absolute instruction. Search engines may generate a different search-result title when they believe another representation better describes the page.

8. Write Useful Meta Descriptions

Meta descriptions do not need to become keyword inventories.

Their job is to summarize the page clearly enough that someone seeing it in search results can understand what they are likely to find.

A service page description might answer:

• What service is this?
• Who is it for?
• What problem does it solve?

Keep descriptions specific to the page.

Duplicating the same generic company description across dozens of URLs wastes an opportunity to provide useful context.

9. Make Mobile Content Complete

Technical SEO cannot be evaluated only on desktop.

Google uses the mobile version of content for indexing.

That means important information should not disappear simply because the viewport becomes smaller.

Responsive design may legitimately change:

• layout
• navigation
• spacing
• presentation
• component order

But the important content and metadata should remain available.

Do not create a beautiful desktop service page containing detailed information and then reduce the mobile version to a headline and contact button.

Mobile should be a different presentation of the experience—not an incomplete version of the page.

10. Treat Website Performance as Part of the Foundation

Performance is not something to think about only after a website becomes slow.

New sites should launch with sensible decisions around:

• image dimensions
• image compression
• responsive images
• font loading
• JavaScript
• third-party scripts
• caching
• database queries
• server response
• lazy loading

That does not mean chasing a perfect benchmark score.

It means avoiding preventable performance problems while the architecture is still easy to change.

We cover this in more detail in why website speed matters for SEO, sales and user experience.

11. Give Images Useful Alt Text

Important content images should have alternative text that describes their meaning or purpose.

For example:

Small business owner reviewing website development costs on a laptop

is much more useful than:

image123

But decorative images do not need SEO keywords forced into them.

Alt text exists primarily to communicate the meaning of an image when the image itself cannot be perceived.

Write it naturally.

12. Handle Redirects Properly During Redesigns

For a completely new domain, URL history may be limited.

For a redesign, it can be extremely important.

If an existing page:

/website-design

moves to:

/services/website-development

the old URL should normally redirect to the most relevant replacement rather than simply becoming a 404.

Before launching a redesign:

1. export the existing URL inventory
2. identify pages receiving traffic or links
3. map old URLs to their replacements
4. implement appropriate redirects
5. test them after deployment

This is one reason a website redesign should preserve what already works rather than treating the existing site as disposable.

13. Use Structured Data Where It Actually Applies

Structured data can help search engines understand specific entities and content types more explicitly.

Depending on the site, appropriate schema may include:

• Organization
• BreadcrumbList
• BlogPosting or Article
• Product
• LocalBusiness
• other supported content-specific types

But structured data should describe what is actually present on the page.

Do not add:

• fake reviews
• fabricated ratings
• hidden content
• irrelevant schema types
• properties simply because they exist in Schema.org

More structured data does not automatically mean better SEO.

Correct structured data is more useful than excessive structured data.

14. Check HTTP Status Codes

Important pages should normally return:

200 OK

Old URLs that permanently moved should normally redirect appropriately.

Missing URLs should return a genuine:

404

or sometimes:

410

Do not create a site where every missing URL returns a visually designed “Not Found” page while technically sending 200 OK.

Search engines need the HTTP response to match what actually happened.

15. Use One Consistent HTTPS Version

Your website should have one primary public URL.

For example, you might choose:

https://example.com

or:

https://www.example.com

Either approach can work. The important part is consistency.

Once the preferred version is selected, alternative versions should redirect to it.

For example, if the canonical version is:

https://example.com

then these variations should not remain independently accessible:

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

They should redirect to:

https://example.com

This prevents the same website from being accessible through multiple competing URL versions.

The preferred hostname should then be used consistently across the site, including:

• canonical URLs
• internal links
• XML sitemap entries
• structured data URLs
• Open Graph URLs

Search engines should receive one consistent answer to the question: “What is the official URL of this page?”

For a new website, choose the preferred HTTPS hostname before launch and make every other hostname or protocol variation redirect to it.

16. Verify the Website in Search Console

Once the site is publicly available, connect it to Google Search Console.

Then check:

• sitemap submission
• indexed pages
• excluded pages
• crawling problems
• canonical selection
• mobile rendering
• Core Web Vitals
• structured data reports where applicable

For important pages, URL Inspection can help confirm how Google sees the URL.

Technical SEO is not finished simply because the launch checklist passed once.

Production behavior matters.

17. Test Structured Data Before and After Launch

If the site contains structured data, validate it.

For example, an Insight article may describe:

• the article
• its author
• publishing dates
• featured image
• publisher
• breadcrumb hierarchy

The markup must correspond to information actually represented on the page.

Structured data can improve how clearly machines understand the content, but valid markup does not guarantee a particular rich result.

Treat it as structured information, not a shortcut to rankings.

18. Crawl the Website Before Launch

Before launching, run a complete crawl of the production-ready website with a tool such as Screaming Frog SEO Spider.

This gives you a practical way to inspect the site in much the same way a crawler moves through internal links and discovers pages.

You do not need to wait until the website is publicly launched.

If the site is available on a staging domain, crawl the staging version first. Screaming Frog can also crawl password-protected development environments when authentication is configured.

A Simple Pre-Launch Crawl

1. Open Screaming Frog SEO Spider.
2. Enter the staging or production-ready website URL.
3. Start a normal Spider crawl.
4. Let the crawl complete.
5. Review the reports before launch.

Check the following areas in particular:

Response Codes

Look for:

• 404 pages
• unexpected 5xx errors
• unnecessary 3xx redirects
• redirect chains
• redirect loops
• internal links pointing to redirected URLs

Important internal links should ideally point directly to the final 200 OK URL rather than passing through redirects.

Page Titles

Review the Page Titles report for:

• missing titles
• duplicate titles
• obviously incorrect titles
• titles copied from staging templates

Every important indexable page should have a useful, page-specific title.

Meta Descriptions

Check for:

• missing descriptions
• duplicated descriptions
• descriptions accidentally inherited from another page

Not every missing meta description is a technical disaster, but important business pages should normally have intentional metadata.

Canonicals

Use the Canonicals report to verify that:

• important pages have the expected canonical URL
• canonical URLs resolve successfully
• canonicals do not point to redirects
• canonicals do not point to 404 or 5xx pages
• indexable pages are not accidentally canonicalized elsewhere

A canonical pointing to a non-indexable URL is a clear configuration problem.

Indexability

Review the site's indexability and directives.

Look specifically for production pages accidentally containing:

noindex

This is particularly important when the staging environment has been intentionally configured as noindex.

Before launch, confirm that the directive has been removed from every page that should appear in search.

If the entire staging site is noindex, Screaming Frog can still crawl it. Configure the crawler so non-indexable URLs are still included in issue checks while performing the pre-launch audit.

Internal Links

Look for:

• broken internal links
• links pointing to old URLs
• links passing through redirects
• important pages with very few internal links
• pages that cannot be reached through the site's normal navigation or content

A page being present in the XML sitemap does not automatically mean the internal linking structure is good.

Images

Check for:

• broken image URLs
• unexpectedly large images
• missing important image references
• incorrect asset paths from the staging environment

Also verify that production image URLs do not still reference a temporary or development hostname.

Sitemap

After the crawl, compare the crawlable/indexable URLs against the XML sitemap.

The sitemap should primarily contain the canonical URLs you actually want indexed.

It should not contain:

• 404 URLs
• redirects
• noindex pages
• duplicate URL variants
• staging URLs

Staging-Specific Problems

Before deployment, search specifically for references to the staging environment.

For example:

staging.example.com
dev.example.com
localhost

Check:

• canonical URLs
• internal links
• image URLs
• Open Graph URLs
• structured data
• sitemap URLs

A site can appear visually correct while still publishing staging URLs inside its metadata.

Run the Crawl Again After Deployment

The staging crawl is not the final check.

After the production deployment, run Screaming Frog again against the real public domain.

This second crawl catches deployment-specific problems such as:

• incorrect production redirects
• missing assets
• environment-specific noindex
• wrong canonical hostname
• HTTP/HTTPS inconsistencies
• staging URLs left in metadata
• production-only 404 or 500 errors

The useful workflow is: crawl staging → fix issues → deploy → crawl production again.

Technical SEO auditing should therefore be an actual launch step, not simply a theoretical checklist item.

Technical SEO Does Not Replace Good Content

A technically perfect website is not automatically a useful website.

You can have:

• perfect canonicals
• a flawless sitemap
• excellent performance
• valid structured data
• clean URLs

and still have pages that do not answer what customers are searching for.

Technical SEO creates the foundation.

Content, relevance, authority, usability and the overall customer experience still determine whether the site deserves attention.

The same principle applies to website conversion: attracting visitors is only useful if the website helps them accomplish something once they arrive.

Final Thoughts

The best time to implement technical SEO is while the website is being built.

At that stage, URL structures can still be changed cleanly.

Templates can enforce consistent metadata.

Image handling can be designed properly.

Structured data can be generated automatically.

Redirect behavior can be tested.

Performance problems can be prevented instead of repaired.

The objective is not to add every SEO technique possible.

It is to launch with a clean, crawlable, understandable and maintainable technical foundation so future SEO work can focus on creating value instead of fixing avoidable problems.