Netlify SEO

Netlify SEO means making sure your site gets crawled and indexed properly despite the platform's quirks. The biggest trap is the automatic Netlify subdomain that runs alongside your custom domain. If you do not redirect it, Google sees two copies of every page. You must set a single canonical hostname and use a [301 redirect](/301-redirect/) from the Netlify.app URL to your domain. I have audited three Netlify projects this year where the client was wondering why their traffic flatlined, and every time the root cause was that the deploy preview URLs were still indexed.

Beyond hostnames, the build output matters more than you might think. Netlify lets you configure asset bundling and minification in your build commands, but if you rely on default settings, your CSS and JavaScript can remain unoptimised. That directly affects Largest Contentful Paint and Cumulative Layout Shift. [Core Web Vitals](/core-web-vitals/) scores on a Netlify site are determined by what you ship, not by the platform's CDN. The CDN only helps with Time to First Byte; the rest is up to your build pipeline.

Metadata behaves the same as on any other platform. Unique title tags and meta descriptions are still required, and Netlify does not generate them for you. If you use a static site generator like Hugo or Eleventy, you have to set those values in your templates. I have seen people rely on the site title being injected by Netlify's environment variables, but that only works for the homepage. For deeper pages, you need explicit per-page meta tags. A sitemap is non-negotiable on Netlify because the platform has no built-in sitemap generator. You must automate its creation in your build script and submit the URL through Search Console after every deploy.

Netlify SEO becomes critical when your site relies on client-side JavaScript for content rendering. If you are building a single-page application with React or Vue, Google may still struggle to index your pages unless you pre-render or use server-side rendering during the build. I have stopped recommending purely client-side rendering for content-heavy Netlify sites because the crawl budget gets wasted on empty shells. A friend's e-commerce storefront built on Gatsby had zero indexed product pages for two weeks until they enabled incremental builds and static generation.

Frequent deployments also raise the stakes. Every time you redeploy, Netlify generates new URLs if you use deploy previews or branch-based deploys. Those URLs can leak into Google if you do not block them with a noindex tag or password protection. If your team pushes dozens of previews a day, you need a [robots.txt](/robots-txt/) that disallows everything except the production branch. The same applies to your sitemap: it should only reference the production domain, not the deploy URLs. I once helped a SaaS startup discover that their staging environment had been crawled because someone forgot to set the X-Robots-Tag header in their _headers file.

Another scenario is large sites with thousands of pages. Netlify builds can time out if you have complex processing. If your build fails, the sitemap is not updated, and new content goes undiscovered. I split large sites into multiple sitemaps and use a sitemap index file to keep the build under the 50,000 URL limit per sitemap. This also makes it easier to monitor which sections Google is crawling. Performance optimisation matters most for mobile users. Netlify's CDN shrinks the latency gap, but if your images are unoptimised or your JavaScript bundles are heavy, mobile Core Web Vitals will suffer. Run Lighthouse after every deploy and set up alerts in Search Console for performance drops.

For a long time I assumed that because Netlify automatically serves the latest deploy, [canonical tags](/canonical-tags/) were optional. I thought a solid redirect chain from the Netlify subdomain to the custom domain would be enough. I was wrong. Google sometimes discovers the subdomain URLs through internal analytics snippets or third-party tools and treats them as separate pages with thin content. Adding self-referencing canonical tags on every page fixed the [duplicate content](/duplicate-content/) warnings in Search Console almost overnight.

I also underestimated how badly missing trailing slashes could fragment search equity. My first Netlify site had URLs without trailing slashes in the navigation but with trailing slashes in the sitemap. Google indexed both variants, and I had to set up redirect rules to normalise them. Now I always enforce a trailing slash policy in my build configuration and test it with a crawl before launch.

Another mistake was treating performance as a one-time optimisation. I ran Lighthouse once, made changes, and called it done. But each deploy can introduce new dependencies or image assets that degrade performance. A client's blog added a large WebP gallery and their Cumulative Layout Shift jumped from 0.05 to 0.35. I had no monitoring in place. I now automatically run Core Web Vitals checks in a GitHub Action after every deploy and block deployments that drop below a threshold. That catches regressions before they reach production.

The final thing I misjudged was how important the _headers and _redirects files are. I thought they were only for advanced use cases, but even simple security headers can affect crawling. A missing X-Frame-Options header caused our site to be blocked from being indexed by a few content aggregators, which I only discovered when reviewing the coverage report. Treat those files as core SEO settings, not optional extras.