Technical SEO for San Francisco companies is mostly technical SEO for software companies: SaaS products, developer tools, AI startups and marketplaces whose websites are built by engineers in modern JavaScript frameworks and shipped as often as the product itself. The problems are rarely missing title tags. They are rendering, architecture and process problems, and they need to be explained in the language your engineering team uses.
Where SaaS and startup sites lose organic traffic
Most San Francisco startups I talk to have the same structure: a marketing site, a blog, documentation, a changelog, sometimes a template or integrations library, and the app itself on a subdomain. Each part is often owned by a different team and sometimes built on a different stack. That is where the technical issues come from.
Rendering and frameworks
Next.js, Nuxt, Gatsby, Astro and similar frameworks can produce very search-friendly sites, but only when pages are server-rendered or statically generated. I often find marketing pages that ship as client-side React with an empty shell, metadata set by JavaScript after load, or internal links built as buttons with click handlers instead of real anchor tags. Google can render JavaScript, but it is slower and less reliable, and many AI crawlers do not run JavaScript at all.
Documentation and developer content
For developer tools, the documentation is often the most valuable organic asset, because developers search for exact error messages, API methods and configuration options. Docs platforms are frequently hosted on a separate subdomain or a third-party service, with versioned copies of every page (/v1/, /v2/, /latest/) competing against each other. The fix is a deliberate canonical strategy pointing older versions at the current one, a single sitemap per docs property and strong links from the marketing site into key docs pages.
Programmatic pages
Integration pages, comparison pages, template galleries and “X for Y” landing pages can be generated by the thousand from a database. Done well, each answers a real search. Done badly, Google ends up with a large pile of near-empty pages it crawls but refuses to index. I review the template, the data behind it and Search Console’s “crawled, currently not indexed” report to decide which pages earn a place and which should be noindexed or removed.
Comparing your options for a site rebuild
Startups rebuild their marketing site often: after a rebrand, a funding round or a new head of marketing. These are the trade-offs I explain when a team is choosing an approach:
| Approach | SEO strengths | Common risks |
|---|---|---|
| Static generation (SSG) | Fast, fully rendered HTML, easy to cache at the edge | Large build times for big programmatic sections; stale content if rebuilds are not triggered |
| Server-side rendering (SSR) | Fresh, fully rendered HTML on every request | Slow server response if data fetching is heavy; caching needs care |
| Incremental or hybrid rendering | Good balance for large sites with changing data | Cache invalidation bugs can serve old canonicals or titles |
| Client-side rendering only | Simple for app-like interfaces | Fine for the logged-in app, poor for any page you want to rank |
| No-code builders (Webflow, Framer) | Marketing team can ship pages without engineers | Less control over rendering details, redirects at scale and structured data |
None of these is wrong on its own. The mistake is choosing one without checking how the pages you need to rank will be delivered to crawlers.
Getting cited by AI search, not only ranked by Google
Many San Francisco buyers, especially technical ones, now ask AI assistants which tool to use before they search Google. Being included in those answers depends partly on content and reputation, but there is a technical layer too:
- Key pages must be readable in raw HTML, because several AI crawlers fetch pages without rendering JavaScript.
- Your robots.txt and bot-management rules (Cloudflare, Vercel firewall and so on) should reflect a deliberate decision about which AI and search crawlers you allow, not a default someone switched on.
- Pricing, feature and integration information should live in clear, crawlable HTML, not only inside images, tabs that load on click or gated PDFs.
- Organization, SoftwareApplication and Product structured data help connect your brand to what it does.
Nobody can promise placement in AI answers, and I will not. What I can do is remove the technical reasons you are being left out.
Fitting SEO into an engineering team’s workflow
San Francisco engineering teams work in sprints, pull requests and CI pipelines, and SEO advice that arrives as a 90-page PDF tends to be ignored. I work the way they do:
- Findings go into your issue tracker as tickets, each with the affected routes, the cause, a suggested fix and acceptance criteria.
- I review pull requests for changes that affect SEO, such as routing, metadata, redirects and robots rules, before they ship.
- Where it helps, I suggest automated checks for the CI pipeline or monitoring (for example, alerting when a noindex tag appears on a production template) so regressions are caught before Google sees them.
- Releases that change URLs get a redirect map and a post-launch check of server logs and Search Console.
Privacy and time zones
California’s privacy law (the CCPA, as amended by the CPRA) affects how cookies, analytics and ad tags are handled. I look at the performance and measurement cost of your consent banner and tag manager; what it needs to say and do legally is for your counsel. On logistics: I work remotely from Karachi and do not have a San Francisco office. Karachi is twelve hours ahead of Pacific Daylight Time and thirteen ahead of Pacific Standard Time, so we meet at the start or end of your day and I work through tickets while your team sleeps.
Rendering reviews, docs canonical strategy and PR review are all part of my technical SEO work. Content strategy for US software companies is under SEO services in the USA, and you can judge my write-ups for yourself in the case studies.
Questions San Francisco startups ask
We are pre-Series A. Is technical SEO worth doing now?
Early is the cheapest time. Getting rendering, URL structure and docs canonicals right before the site has thousands of pages avoids an expensive cleanup later. An early engagement can be short: an architecture review plus a checklist your engineers own.
Should our docs live on a subdomain or a subfolder?
Either can rank. A subfolder keeps signals on one host and is generally simpler to manage for SEO; a subdomain is fine if it is well linked from the main site and properly configured. I usually advise based on what your docs platform supports rather than forcing a migration.
Our app pages are getting indexed. Is that a problem?
It can be. Logged-out app routes, share links and workspace URLs can leak into the index and expose thin or private-looking pages. I identify the patterns and recommend noindex headers, authentication checks or robots rules depending on the case.
If your engineering team ships fast and organic traffic is not keeping up, I can review your rendering and site architecture for free and send the findings as tickets. Reach out here to set it up.