Nurullah Aydın
Digital
4 min read
Technical SEO checklist for a business website launch
Technical SEO is easiest to fix while the website structure is still visible to the people building it. By launch week, page addresses, templates, content fields, and third-party scripts have already shaped the result. Use this checklist during development, then run it once more against the production domain before announcing the site.

01
Confirm which pages should appear in search
List every public page that should be indexed and every utility page that should stay out. Staging environments, internal search results, duplicate filter pages, and unfinished routes should not enter the public index by accident.
Check robots.txt, page-level robots directives, authentication, and canonical tags against that list. A page can be linked in the navigation and still carry a noindex directive left over from development. The production domain should also be the canonical source after launch.
Open important pages without relying on client-side clicks that a crawler may not reproduce. Each one should have a stable URL and at least one crawlable link from another relevant page.
02
Review titles, descriptions, and heading structure
Every important page needs a unique title that names its subject. Keep the useful words near the beginning and add the brand where it helps distinguish the result. Write a specific meta description for the page instead of copying the homepage summary across the site.
Use one visible H1 that matches the page's main subject. Arrange H2 and H3 headings by meaning, without skipping levels for visual size. Screen styling can change how a heading looks; the document structure should still make sense when read as an outline.
Compare the search result promise with the first screen. A title about custom admin panel development should open on that service, not on a broad statement about digital experiences.
03
Test the mobile path on a physical device
Load the production-like build on a phone over an ordinary connection. Check how quickly useful content appears and whether large images, video, fonts, or third-party scripts delay interaction. Serve images close to their displayed size and reserve their layout space to reduce movement while the page loads.
Complete the main task with one hand. Open the menu, follow a service link, use the quote or booking form, and confirm the result. Verify field labels, error messages, focus order, tap targets, and keyboard behavior. A contact button that sits on screen but fails to open the intended channel has not passed the review.
Measure performance, then inspect the cause of any poor result. A score alone does not identify which asset or script should change.
04
Map old addresses to the new structure
For a redesign, export the existing URLs before the new site replaces them. Keep addresses that still make sense. Where a page has moved, add a direct permanent redirect to the closest new equivalent. Sending every old URL to the homepage discards context and gives visitors a poor landing point.
Test redirects for loops and chains. Update internal links so the new site points directly to the final URL. Then check canonical tags for the same preferred address, including the chosen protocol, hostname, and trailing-slash convention.
Review the 404 page and status code as well. A helpful design cannot compensate for a missing page that incorrectly returns a successful 200 response.
05
Publish clean sitemaps and language references
The XML sitemap should contain canonical, indexable URLs from the production site. Remove staging addresses, redirects, error pages, and routes excluded from search. Submit the sitemap through the relevant search tools after launch and monitor whether important pages are being discovered.
Multilingual sites need reciprocal hreflang references between equivalent pages. Use the correct language and regional codes, and include a sensible default where the routing calls for one. Each referenced URL must resolve successfully and point back to its alternatives.
Translated navigation does not prove the setup. Language metadata and copy written for each market are separate checks.
06
Finish with content control and monitoring
Confirm that the team can update the fields it owns after handoff. If editors can publish service pages or articles, the CMS should support titles, descriptions, headings, image alternatives, and clean URLs with appropriate safeguards.
Before release, verify analytics and search-console access, form delivery, consent behavior where applicable, and the main conversion events. Record the launch date and crawl a final production snapshot so later problems can be compared with a known state.
Keep the completed checklist with the release notes. When a later content or routing change touches one of these controls, rerun the affected checks instead of waiting for the next redesign.
Share the business problem, intended users, and required function. We will identify the deliverables the scope needs.