← All field notes

Technical SEO Checklist for Custom Software and Application Sites

Check a custom site's real page types and live responses. Focus on discovery, meaningful content, correct URLs and an experience visitors can use.

SEOSaaSSoftware

A custom website can produce many kinds of pages from the same application. A service page, a database-driven listing and a filtered search result may look similar while behaving differently for search engines.

Build the technical SEO review around those page types. The aim is to find where useful information becomes hard to discover, duplicated or unavailable, then fix the source of the problem.

List what the application makes public

Include main pages, detail pages, categories, pagination, files and alternate domains. A route is an address pattern the application knows how to handle. Choose representative addresses from each pattern and decide which should appear in search.

Compare the list with navigation and the XML sitemap. Crawlability means a search engine can reach and retrieve a page. A publicly accessible address can still be difficult to discover if no relevant page links to it.

Inspect what each address returns

Record the status code, final address after redirects, title, description, main heading, meaningful content and indexing instructions. HTTP 200 normally indicates a successful response; a nonexistent page should return an appropriate missing-page status, even when it has a helpful design.

Compare the initial HTML with what appears after scripts run. Google can process JavaScript, but scripts and their supporting resources introduce additional dependencies. Its JavaScript SEO documentation describes that processing.

Resolve genuine duplicate versions

A canonical tag tells search engines which version is preferred. Review it alongside redirects, internal links and the sitemap. Google's canonicalization guidance explains the available signals; a declared preference is not a guaranteed selection.

Check protocol and hostname alternatives, tracking parameters and filtered pages. Pagination needs a decision suited to its content. Avoid directing unrelated pages to one canonical address simply because some pages are less useful.

Check the journey on a phone

Open representative templates with realistic content and production scripts. Look for slow main content, moving layouts, delayed controls and menus or overlays that block the task. Confirm that links work without depending on an obscure interaction.

For each sampled address, keep a short record: where it is linked, what it returns, which version is preferred and whether it belongs in the sitemap. Include a missing address as well as successful ones.

Prioritize and recheck

Rank problems by customer impact, confidence and effort. A shared template or routing fix may resolve many affected pages, but verify the actual public responses after release.

Automate stable checks such as broken links and incorrect status codes. Retain human review for whether each page answers its intended question. The checklist supports that judgment; it cannot replace it or promise a search result.