Technical SEO audit for startups:

A technical SEO audit checks whether search engines can find, fetch, render and index the pages on your site. For a startup, run it in this order: list your key pages, check each one is indexable, then work through status codes, redirects, canonicals, robots.txt, sitemaps, rendering, mobile and speed.

Most startup sites are small enough to audit with free tools in a working session. Google says “most sites pass the technical requirements without even realizing it” (Google), so the job is to find the few things that are wrong, not to rebuild the site. This guide covers the technical half of a SaaS SEO audit. The page by page half is how to do a content audit.

In short

• Start with a list of the pages that matter, and a baseline from Search Console.
• Check each page for a 200 status, no noindex, no robots.txt block and a self canonical. Our free indexability checker does this for one URL.
• Then confirm in Search Console what Google actually indexed.
• Fix redirects and duplicates so each page has one URL.
• Make sure the main content is in the HTML and the mobile page has the same content.
• Check Core Web Vitals last. They matter, but they rarely stop a page being indexed.

What you need

• Google Search Console, verified for the domain. URL Inspection, the Page indexing report, the Sitemaps report and the Core Web Vitals report are all inside it.
• Bing Webmaster Tools for Bing’s own indexing and sitemap reports.
• PageSpeed Insights for speed on one URL.
• Your browser’s view source, and our free indexability checker, meta tag checker, schema markup checker and AI crawler checker.

A desktop crawler helps on sites with many templates. On a small site, a list of URLs in a spreadsheet is enough.

Step 1: list the pages that matter

Write down every page a buyer should be able to find from Search: the homepage, pricing, product and feature pages, use case and integration pages, comparison pages, docs and the blog posts that lead to sign-ups. Add one example of each template, such as one docs page and one changelog entry.

Next to each URL, note its clicks and impressions from the Performance report in Search Console. That is your baseline.

Step 2: check each page is indexable

Google needs three things before a page can be indexed: Googlebot isn’t blocked, the page returns a 200 status code, and the page has indexable content (Google). On your side, these are the usual blockers:

• A status code other than 200. Google says “Client and server error pages aren’t indexed.”
• noindex in a meta robots tag or an X-Robots-Tag header (Google).
• A robots.txt rule that blocks the path for Googlebot.
• A canonical that points to a different URL, which tells Google to index that one instead.

Paste each URL into the free indexability checker. It reads the status and redirect chain, meta robots and X-Robots-Tag, your robots.txt rules for Googlebot, the canonical tag and whether the URL is in your sitemap, and gives a fix for each problem it finds. It can only see what your site tells Google, so confirm with URL Inspection in Search Console, which shows whether the URL is on Google.

If a page is not indexed, the Page indexing report gives the reason. Our guide to website not indexed by Google lists each status and its fix.

Step 3: status codes and redirects

Check the whole site for broken pages and redirect chains, not just the key pages.

• 404s on purpose are fine. A deleted page should return 404 or 410. Fix the internal links that still point to it.
• Soft 404s are not. A page that says “not found” but returns 200 shows up as a soft 404 in Search Console.
• 5xx errors and firewalls. Server errors and bot protection can block Googlebot without anyone on the team seeing it. Check your CDN and firewall rules.
• Redirects. Google’s crawlers “follow up to 10 redirect hops” by default (Google). Keep chains to one hop, use permanent redirects for pages that moved for good, and update internal links to the final URL.

After a domain change or a rebuild, check the old URLs too. Every old URL that had links or traffic should redirect to the closest new page, not to the homepage.

Step 4: one URL per page

The same page often answers on several URLs: http and https, www and non-www, with and without a trailing slash, and with tracking parameters. Pick one version and make every signal agree with it.

Google lists redirects and rel=”canonical” as strong canonical signals and sitemap inclusion as a weak one (Google). So:

• Redirect the other host and protocol versions to the one you chose.
• Give every indexable page a canonical tag that points to itself, as an absolute URL.
• Put only canonical URLs in the sitemap and in internal links.

If Search Console says Google chose a different canonical than yours, look for the signal that disagrees, such as internal links to the non-canonical version.

Step 5: robots.txt and sitemaps

robots.txt. Read the file line by line. Google says robots.txt manages crawling and “is not a mechanism for keeping a web page out of Google” (Google). Block only private routes such as the app, admin or internal search. To keep a page out of Google, use noindex and leave it crawlable, since a blocked crawler never sees the noindex. The AI crawler checker shows which search and AI bots your rules allow, and AI crawlers and robots.txt lists the user agents.

Sitemaps. Google says a sitemap helps it find URLs but “doesn’t guarantee that all the items in your sitemap will be crawled and indexed” (Google). List only canonical URLs that return 200 and are not noindexed. Reference the sitemap in robots.txt and submit it in Search Console and Bing Webmaster Tools. The Sitemaps report shows when Google last read it. The free sitemap checker checks the file itself: valid XML, the URL limit and every URL in it.

Step 6: rendering and JavaScript

Many startup sites are React apps. Google renders JavaScript, but “If the content isn’t visible in the rendered HTML, Google won’t be able to index it” (Google). The same page says server side or pre-rendering is still a good idea because “not all bots can run JavaScript”.

• View source on a key page. If the main text is not in the HTML you receive, it depends on JavaScript.
• Use URL Inspection’s rendered HTML to see what Google sees.
• Check that links are real a elements with an href. Google says it can generally only crawl links in that form (Google).
• Check that titles, descriptions and canonicals are in the server HTML, not set later by a script. The meta tag checker reads the server HTML.

On Next.js, our Next.js technical SEO checklist covers the App Router settings for each of these.

Step 7: mobile, speed and HTTPS

Mobile. Google “uses the mobile version of a site’s content, crawled with the smartphone agent, for indexing and ranking” (Google). Content hidden or removed on mobile is content Google may not index. Check that mobile pages have the same text, headings, links and structured data as desktop.

Core Web Vitals. Google’s targets are Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint under 200 milliseconds and Cumulative Layout Shift under 0.1 (Google). The Core Web Vitals report groups pages by status. PageSpeed Insights shows field data for one URL when it has enough, and a lab test either way. Fix the templates that fail, starting with the ones that carry the most pages.

HTTPS. Every page should load over HTTPS, and http should redirect to it in one hop.

Step 8: structured data and AI access

Structured data. Run key pages through the schema markup checker. Google says not to mark up information that is not visible on the page (Google). Schema markup for SaaS covers which types to use.

AI search. For Google’s AI Overviews and AI Mode, the requirement is the same as Search: the page “must be indexed and eligible to be shown in Google Search with a snippet” (Google). ChatGPT, Perplexity and Claude use their own crawlers, so check your robots.txt and firewall rules for them too. The rest is in our AEO and GEO checklist.

Step 9: write it up and fix in order

For each problem, write the URL or template, what is wrong, the fix and who owns it. Fix in this order:

1. Anything that stops a key page being indexed (status, noindex, robots.txt, canonical).
2. Redirects and duplicates that split one page across several URLs.
3. Rendering problems that hide content or links.
4. Mobile differences, then speed.

After each release, re-run the indexability check on the pages you changed, and request indexing in URL Inspection for the ones that matter most. Google says asking for a recrawl “multiple times for the same URL won’t get it crawled any faster” (Google), so ask once.

FAQ

What is a technical SEO audit?

A check of whether search engines can find, fetch, render and index your pages. It covers status codes, redirects, canonicals, robots.txt, sitemaps, rendering, mobile, speed and structured data. It does not judge the content itself. That is a content audit.

Can I do a technical SEO audit for free?

Yes. Search Console, Bing Webmaster Tools and PageSpeed Insights are free, and so are our indexability, meta tag, schema and AI crawler checkers. A paid crawler mainly saves time on sites with many templates.

What should a startup fix first?

Anything that stops a key page being indexed: a status other than 200, a noindex, a robots.txt block or a canonical pointing elsewhere. Speed and markup come after.

Does a noindex or robots.txt block hurt AI search visibility too?

For Google’s AI features, yes, because a page has to be indexed and eligible for a snippet. ChatGPT, Perplexity and Claude follow their own crawlers’ robots.txt rules, so a block on those user agents keeps you out of their search results.

How often should a startup run a technical SEO audit?

Spot check key pages after every release, since deploys are how a stray noindex or broken canonical usually ships. Run the full audit each quarter, after a redesign or domain move, or when Search traffic drops.

Want the technical fixes done for you?

Ignura automates SEO and GEO, and you approve what goes out. Audits and fixes are part of our technical SEO work, and the seed-stage SaaS page covers where most early sites start. See the pricing page for how we price it.

Book your free Growth Check