The SEO mistakes most developers make
The first 80% of SEO lives in the code, not in the copy. Five mistakes I shipped to production — including the one where staging environments leak into Google.
SEO was the last layer added to FisEvents, in the same April sprint that brought ArcJet and the GDPR work. By the time I addressed it, three of the five mistakes below had already shipped to production. Removing them took two weeks. Diagnosing them took longer.
The deeper reason SEO arrives last in most projects is that software teams treat it as marketing's problem. That is the first mistake. The first 80% of SEO lives in the code, not in the copy. No amount of keyword-rich content will save a site whose architecture has decided it should not rank.
A few mistakes worth describing — because each is invisible until it costs months of compounding traffic.
1. Staging environments leaking into Google.
Every Next.js project deployed to Vercel gets free preview URLs: your-app-pr-42.vercel.app, your-app-git-feature-branch.vercel.app, and the canonical your-app.vercel.app. These URLs are public. They are also crawlable by default. Unless you actively block them, Google will eventually index a half-finished feature branch with broken copy, mismatched language strings, and demo data. Once that page is in the index, it takes weeks to remove — and during those weeks, it competes with the real site for ranking signal.
The fix is one configuration check: noindex, nofollow headers when the deployment is not production. Three lines of code. A two-month traffic problem if missing.
This is the same lesson that came up around security: every URL on the open internet is public the moment it exists. There is no "private staging." There is "staging that has not been discovered yet."
2. Sitemap and robots.txt as afterthoughts.
Most developers generate a sitemap on deploy day, paste a robots.txt from a Stack Overflow answer, and never look at them again. The result is one of two failure modes: a sitemap that omits half the indexable pages, or a robots.txt that blocks something important by accident. Both are silent until someone checks Search Console months later and discovers that the pricing page has been excluded from indexing since launch.
The fix is to treat sitemap and robots as application configuration: generated by code, environment-aware, version-controlled, reviewed in pull requests. A sitemap that auto-discovers indexable routes is a one-time investment that prevents the problem forever.
3. One landing page for many use cases.
A SaaS product almost always serves more than one customer profile. FisEvents has yoga teachers, workshop hosts, course organizers, food and wine event runners. Cramming all of them into a single homepage is comfortable for the marketing team and catastrophic for SEO. Each profile searches for different phrases. "Booking platform for yoga workshops" and "event signup for cooking classes" are different intents that need different landing pages.
The fix is dedicated landing pages per use case, each indexed separately, each ranking for its own long-tail keywords. The homepage exists to brand the product. The landing pages exist to capture intent.
4. Client-side rendering of marketing pages.
Application UI rendered on the client is fine. Marketing content rendered on the client is fragile. Google's crawler does run JavaScript, but inconsistently and slowly, and other crawlers — Bing, social-preview bots, AI-search agents — handle it poorly or not at all. Pages that should rank (landing pages, blog posts, pricing) should be server-rendered or statically generated. This is not a 2018 problem. It is a 2026 problem, because the rise of AI-driven search has multiplied the number of bots that read HTML and never run JS.
5. Missing structured data.
Event listings without schema.org/Event markup are invisible to the rich-snippet treatment that Google gives to event-related searches. The same listings with the markup get a card with date, location, and price directly in the search result. Structured data is one of the few SEO investments where the work is hours and the lift is permanent.
Each of these mistakes shares a property: invisible from the inside, costly from the outside, slow to fix once the damage is done. SEO is not the marketing department's deferred problem. It is an architectural property of the application, set at build time, debugged in Search Console months later.
For founders evaluating a SaaS that wants to grow through organic discovery, the right SEO questions for the engineer are not about keywords. They are: what is your robots.txt strategy across environments? Do you have noindex on staging? How many landing pages do you ship per use case? Which of your content pages are server-rendered, and why? If the answers are vague, the product will not rank — not because the content is bad, but because the architecture has already decided.
Next week: how I removed every social login and what it simplified.
— Christian