By Mehdi HassanMost technical SEO guides are written for sites with millions of URLs: ecommerce catalogs, marketplaces, news publishers. If you run a startup or SaaS marketing site with somewhere between 10 and 200 pages, most of that advice is noise. Crawl budget, log-file analysis and faceted navigation rarely matter at your size. A handful of basics matter a lot, and they're usually decided by how the site was built.
This guide covers the small set of technical SEO tasks that do the work on a marketing site, explains each part in plain English and points to a deeper guide for each one. If you're about to launch, jump to our technical SEO checklist for new website launches.
What is technical SEO for websites?
Technical SEO for websites is everything that affects whether search engines can find, fetch, render, understand and index your pages, separate from what the pages say. Content SEO decides whether a page deserves to rank. Technical SEO decides whether it gets the chance.
In practice it covers five jobs. Access: crawlers can reach the page and aren't blocked. Rendering: the content exists in the HTML a crawler receives. Indexing control: the right URLs are indexed, once each. Understanding: titles, headings, links and structured data make the page's topic and its place on the site clear. Experience: pages load fast and work on phones.
There's also a newer audience to think about. AI answer engines such as ChatGPT search, Perplexity and Google's AI features read the same pages. Google says its AI features need no special markup beyond normal SEO, which is good news: the same technical basics serve both. The difference is that many AI crawlers are less forgiving than Googlebot, especially about JavaScript.
Layer | Question it answers | Where it breaks on small sites |
|---|---|---|
Access | Can crawlers reach the page? | robots.txt left blocking from staging |
Rendering | Is the content in the HTML? | Client-side React or heavy JS widgets |
Indexing | Is the right URL indexed once? | Missing canonicals, UTM duplicates, stray noindex |
Understanding | What is this page about and how does it fit? | Weak titles, orphan pages, no schema |
Experience | Is it fast and usable on mobile? | Third-party scripts hurting INP |
Change | Do rankings survive edits and redesigns? | Missing redirects and redirect chains |
What matters most on a 10 to 200 page marketing site?
On a small marketing site, seven things decide almost all technical SEO outcomes: rendering, robots.txt and sitemap, canonicals, internal links, structured data, page speed and redirects. Get those right and you can ignore most of what enterprise checklists ask for.
The reason is scale. A 60-page site gets crawled completely and often, so crawl budget is not your constraint. Your constraint is usually that a few important pages are invisible, duplicated or broken. One bad setting, such as a sitewide noindex left over from staging, can wipe out the whole site. That's why small-site technical SEO is about getting a short list exactly right, not covering a long list loosely.
- Rendering: every page's main content is in the server-sent HTML.
- Access: robots.txt allows search and answer-engine crawlers on production and blocks staging.
- Sitemap: an XML sitemap lists only canonical, indexable 200-status URLs.
- Canonicals: each page declares one self-referencing canonical, and parameter URLs point back to it.
- Internal links: every page you want ranked is linked from navigation or a hub page.
- Structured data: Organization, WebSite, Article and BreadcrumbList cover most needs.
- Speed and redirects: pages pass Core Web Vitals and every changed URL has a direct 301.
Can Google and AI crawlers read your pages?
Google can render JavaScript, but many AI crawlers don't, so the only safe choice for marketing pages is HTML that's complete before any script runs. That means static generation or server-side rendering, which Next.js, Webflow and Framer all provide by default.
Googlebot fetches a page, then queues it for rendering in a headless browser. Content that appears only after JavaScript runs usually gets indexed, but later and less reliably. AI crawlers that power answer engines commonly fetch the raw HTML and stop there. A pricing table or FAQ injected by a client-side script may simply not exist to them.
The fix is architectural, not a plugin. Build marketing pages with static generation or server rendering, and keep JavaScript for enhancement: animations, interactive calculators, forms. Our guide to JavaScript SEO and AI crawlers explains how to check what a crawler actually sees, and the Next.js SEO checklist covers the framework settings.
Access is the other half. Your robots.txt should allow the crawlers you want, including Googlebot, Bingbot, OAI-SearchBot and PerplexityBot, and your XML sitemap should list every page you want indexed. The robots.txt and sitemap setup guide has copy-ready examples, including what to do about AI training crawlers and staging sites.
How do you control which URLs get indexed?
You control indexing with three tools: canonical tags that name the preferred URL, noindex tags that keep a page out of the index, and redirects that retire old URLs. Used together, they make sure each piece of content is indexed once, at the URL you chose.
Marketing sites create duplicate URLs without anyone meaning to. UTM-tagged links from campaigns, trailing-slash and non-slash versions, uppercase paths, paginated blog archives and A/B test variants can all serve the same content at different addresses. Google picks one, and it may not be the one you want. A self-referencing canonical on every page solves most of this, and our guide to canonical tags covers the cases that need more thought.
Parameters and pagination deserve their own rules, especially on blogs, changelogs and resource libraries. The guide to URL parameters and pagination explains which to index and which to canonicalize. When pages still don't show up, the Search Console status tells you why: our guide to pages not indexed by Google goes through each status and its fix.
Situation | Use | Why |
|---|---|---|
Same content at several URLs | Canonical tag | Consolidates signals to one URL |
Page should exist but not rank (thank-you, login) | noindex | Users can reach it, search can't list it |
Page moved or merged | 301 redirect | Sends users and link equity to the new URL |
Page gone with no replacement | 404 or 410 | Tells crawlers to drop it |
Staging or preview site | Password or noindex plus block | Keeps a duplicate site out of results |
How should a marketing site be structured and linked?
A marketing site should be shallow and grouped: every important page within two or three clicks of the home page, related pages linked to each other, and topic hubs that link down to their detail pages. Structure tells search engines which pages matter most and how they relate.
Most small sites get this wrong in one of two ways. Some hide valuable pages, such as use-case pages or comparison pages, so they're only reachable from a footer link or not at all. Others link everything to everything, so nothing stands out. A better pattern is hub and spoke: a pillar page per topic, detail pages under it, and links running both ways with descriptive anchor text.
Internal linking is also the cheapest technical lever you have, because you control it completely. A new blog post with no links pointing to it may wait weeks to be crawled. The same post linked from a relevant hub and two related articles usually gets found within days. Our internal linking strategy for small marketing sites shows how to design this into navigation from the start.
Hypothetical example: structuring a 40-page SaaS site
For example, suppose a SaaS company has a home page, pricing, six feature pages, four use-case pages, three comparison pages, an about page and 24 blog posts.
A flat structure puts all of it in a mega menu and a blog index. A hub structure groups features under a Product overview page, use cases under a Solutions page, and blog posts under three topic hubs that each link to the matching feature and use-case pages. Every page is two clicks from home, and every blog post passes visitors toward a product page instead of dead-ending.
Which structured data is worth adding?
For most marketing sites, four schema types cover nearly everything: Organization, WebSite, Article for blog posts and BreadcrumbList for hierarchy. Add SoftwareApplication or Product if you sell software, and FAQPage only where a visible FAQ exists.
Schema helps search engines understand entities: who you are, what you sell, who wrote an article. It can make pages eligible for some rich results. What it doesn't do is guarantee rankings or AI citations. Ahrefs ran a controlled test in 2026 and found no significant lift in AI citations from adding schema, and Google has narrowed which sites get FAQ rich results. Treat schema as accurate labelling, not a ranking trick.
The practical rule: mark up what is visibly on the page, keep it consistent with your other profiles, and validate it with Google's Rich Results Test. Our guide to schema markup for websites lists the properties worth filling in for each type.
How fast does a marketing site need to be?
A marketing site needs to pass Google's Core Web Vitals in field data: Largest Contentful Paint, Cumulative Layout Shift and Interaction to Next Paint. Of the three, INP is the one sites fail most, and the usual cause is third-party scripts, not your own code.
- Share of Next.js sites passing INP in Q2 2026 field data (corewebvitals.io)
- ~2/3
- Median INP for Next.js sites in the same data, above Google's threshold for a good score
- ~236ms
- Core Web Vitals Google measures: LCP, CLS and INP
- 3
Speed is a tiebreaker more than a ranking engine, but slow pages lose visitors before they rank. On marketing sites the biggest wins are usually boring: fewer tag-manager scripts, chat widgets that load after interaction, properly sized images and fonts that don't shift the layout. Check the Core Web Vitals report in Search Console, which uses real-user data, before acting on a lab score from a single test run.
What breaks during a redesign or migration?
Redesigns and platform migrations cause most of the serious ranking losses on small sites. The usual causes are missing or chained redirects, noindex tags copied from staging, changed canonicals and content that was cut without anyone checking its traffic.
Industry write-ups on redesign recoveries draw a useful line. A dip of under 10% that recovers within a few weeks is normal while Google reprocesses the site. A drop of 30 to 50% that persists is a signal that something technical broke. The good news is that the causes are predictable, so they're preventable with a plan.
That plan starts with a redirect map for the redesign, built before launch from a crawl, Search Console data and backlinks. It continues with a launch-day check of robots.txt, canonicals and the sitemap, and a few weeks of monitoring. The full process is in our website migration SEO checklist. Old redirects pile up too, and our guide to fixing broken links and redirect chains covers the monthly cleanup.
What technical SEO can a small site skip?
A small marketing site can safely skip most crawl-budget work, log-file analysis, complex faceted-navigation rules, JavaScript prerendering services and exotic schema types. These matter for sites with hundreds of thousands of URLs, not for sites with a few hundred.
Pros
- Skip crawl-budget tuning: Google crawls small sites fully and often.
- Skip log-file analysis unless you suspect a crawler is being blocked.
- Skip prerendering services if your framework already renders on the server.
- Skip schema types with no matching visible content.
Cons
- Don't skip a sitemap just because the site is small; it speeds discovery of new pages.
- Don't skip canonicals; small sites still create parameter duplicates.
- Don't skip redirects on a redesign, even for pages you think nobody visits.
- Don't skip accessibility basics; semantic HTML helps crawlers and people.
Accessibility overlaps with technical SEO more than most people expect. Proper headings, alt text, link text and semantic HTML help screen readers and crawlers in the same way. If you're working through that list, the WCAG 2.2 checklist is a good companion, and SaaS teams selling into Europe should read our note on the European Accessibility Act.
Who should own technical SEO on a startup website?
On a startup website, technical SEO is best owned by whoever builds and maintains the site, with an SEO specialist auditing occasionally. Most fixes are code or CMS changes, so a team that can only diagnose will always wait on a team that can ship.
The common failure is an audit that produces a long spreadsheet nobody implements, because the developer who built the site has moved on and the marketing team can't edit templates. A better split is to keep strategy and content in-house, run a periodic audit using a checklist like our SEO audit checklist for startup sites, and give implementation to a team that can design and code. Our guide to technical SEO services goes through what to outsource and what to keep.
Where should you go next?
Each guide below goes deeper into one part of technical SEO for marketing sites. They're grouped by the job they do, so start with whichever matches your current problem.
If you need to | Read |
|---|---|
Launch a new site safely | |
Make sure crawlers can read your pages | JavaScript SEO: will Google and AI crawlers see your content? |
Set up crawl and discovery files | |
Fix duplicate URLs | |
Find out why pages aren't indexed | |
Add structured data | |
Structure and link the site | |
Redesign without losing rankings | |
Decide who does the work |
If you're launching on a SaaS product timeline, the SaaS SEO checklist for launch day pulls the most urgent items into one list.
