Technical SEO in San Francisco

JavaScript frameworks and what crawlers receive

Marketing sites at San Francisco startups are often built by product engineers with the same frameworks they use for the app. That brings speed and consistency, but it also brings a familiar risk: pages where the main content, internal links or metadata only appear after client-side scripts run. Search engines can render JavaScript, yet rendering is delayed and not assured, and other crawlers, including those used by AI assistants, may not render at all.

My review compares the raw HTML a crawler first receives with the fully rendered page, template by template. Typical findings include navigation links built as click handlers rather than real anchors, titles and canonical tags set late by scripts, content loaded only after user interaction, and error pages that return a normal status code.

Most modern frameworks support server or static rendering, so the fix is usually a configuration or architecture choice rather than a rewrite. I set out which templates need it first and why. The general approach is described on the JavaScript SEO page, and the US-wide view of platform issues sits on the US technical SEO page.

Versioned documentation and generated API references

Developer-focused companies in the city often publish documentation for several product versions at once. Each version may have its own copy of every page, with only small differences between them. Search engines then have to choose among near-identical pages, and they sometimes rank an outdated version above the current one, sending developers to instructions that no longer work.

I agree a version policy with your docs owners. Usually the current version is the indexable default, older versions remain available for existing users but point their canonical to the current equivalent or are kept out of the index, and a clear banner tells readers when they are viewing an old version. Where a page exists only in an old version, it is handled separately rather than forced into a pattern.

Generated API references raise a related problem. Automatically produced pages for every endpoint, parameter or class can create a large volume of thin URLs. I help decide which reference pages carry real search value, which should be consolidated and how they link to the guides that explain them. Docs generators vary in how they support these controls, so the recommendations are written for the tool you actually use.

Preview builds, staging hosts and app screens in the index

Modern hosting platforms create a fresh preview address for every branch or pull request. That is excellent for review, and a quiet problem for search. If a preview link is shared publicly, posted in an issue tracker or embedded somewhere crawlable, search engines can find it and index a copy of your site. Staging hosts and old marketing subdomains create the same risk, as do app login and signup screens that were never meant to rank.

I start by finding what is already indexed across every host your company uses, not just the main domain. Then I recommend controls that fit your deployment pipeline: authentication on preview and staging environments where possible, noindex headers set automatically for non-production builds, and canonical tags that always point to production. I also explain why a robots disallow rule alone does not remove pages that are already indexed.

The aim is a rule built into the pipeline, so the protection does not depend on someone remembering a step during a busy release. The broader audit method is described on the technical SEO audit page.

Marketplaces, directories and user-generated profiles

Several kinds of Bay Area companies run sites built from user content: marketplaces for freelancers or services, directories of tools and vendors, community platforms with member profiles. These sites can produce an enormous number of URLs, and many of them are thin: empty profiles, listings with no description, search result pages with a single item.

Indexing everything dilutes the site and wastes crawl attention on pages that will never rank. Indexing too little hides valuable content. I help define quality rules that decide which pages are indexable, such as a profile with a real description, reviews or completed work, and make sure templates apply those rules automatically as content changes.

Sitemaps and internal links then follow the same logic, pointing to pages that meet the bar and not to those that do not. Faceted search and filtered listings get their own rules, so useful combinations can be indexed while endless permutations stay out. Where a company wants to create pages at scale deliberately, the approach on the programmatic SEO page applies.

Locale folders for a product sold around the world

Many San Francisco companies sell globally from early on, and their sites add languages and regional versions as they grow. The technical setup often lags behind. Hreflang tags may be missing or point to the wrong pages, language switchers may rely on scripts or cookies, and automatic redirects based on visitor location can stop crawlers from ever seeing some versions.

I review the locale structure as a whole: folder or subdomain choices, hreflang annotations, self-referencing canonicals for each locale, how untranslated pages are handled, and whether redirects allow both visitors and crawlers to reach every version. Localized documentation and pricing pages often need the most attention because they change frequently.

Translation quality sits outside my role: the wording in each language belongs to fluent colleagues on your side or to the translation agency you use. My focus is that the right version is discoverable and served to the right market. Strategy for entering new markets is covered on the international SEO strategy page. For the content and pipeline side of search in the city, see the San Francisco SEO consultant page, or send your site for a first look.