SEO for Static Sites: 8 Problems to Watch For

But easier to build doesn’t necessarily mean easier to optimize.

WordPress and other CMSs quietly handle many SEO basics through plugins and built-in functionality, from canonicals and sitemaps to redirects, metadata, schema, and 404 handling.

With a static site, much of that work becomes your responsibility.

As Suganthan puts it,

That doesn’t make static sites bad for SEO. It just means you need to know what your CMS used to do for you, and what you now need to build, configure, and monitor yourself.

Static sites can be fast and technically clean, but they also leave more room for small SEO mistakes to slip through, since no CMS or plugin handles things in the background.

That becomes even more important with vibe-coded sites. AI can build the page, but it won’t necessarily know which SEO conventions you want it to follow across the entire site.

Here are some of the most common issues to watch for:

A website audit is one of the easiest ways to catch these problems.

Ahrefs’ Site Audit crawls your site and surfaces over 170 technical SEO issues that may otherwise go unnoticed, which is especially useful when there’s no CMS or SEO plugin checking them for you.

Static sites can accidentally make the same page accessible at two URLs, such as /page and /page/.

This usually happens because your static framework and hosting platform have different defaults for trailing slashes.

Your framework might generate one version while your host serves or redirects to another.

The problem is that your canonical tags, internal links, and redirects can then disagree about which URL is the preferred version. At best, that creates unnecessary redirects. At worst, search engines may see duplicate URLs, and ranking signals can get split between them.

Choose one URL format, with or without a trailing slash, and use it consistently across your site.

Configure both your framework and hosting environment to follow the same convention, then check that your canonical tags and internal links point to the version that actually resolves.

You can also crawl the site with Ahrefs’ Site Audit to find canonical conflicts, redirect chains, and internal links pointing to non-canonical URLs.

On a static site, your XML sitemap is usually generated by code. The problem is that the sitemap generator may not know which pages you’ve marked as noindex.

That means URLs such as drafts, thank-you pages, confirmation pages, or other pages you don’t want in search can still end up in the sitemap.

This happens because there’s no CMS plugin keeping everything in sync for you. A page might be excluded from your main navigation or marked noindex, but still appear in the sitemap or RSS feed unless you’ve explicitly built logic to exclude it.

The setup can also become fragile as the site grows. A basic flat sitemap is fairly easy to manage, but things get more complicated once you need to split sitemaps by page type, exclude certain sections, or apply different rules to different templates.

Static sites can have a similar problem with robots.txt.

Depending on your framework and deployment setup, one may not be created automatically, so it’s worth checking that the file exists and contains the crawl rules you actually want. Just remember that robots.txt controls crawling, not indexing, so it shouldn’t be used as a substitute for noindex.

Create one rule for pages you want to keep out of search. For example, mark them noindex: true, then tell your sitemap and RSS feed to ignore any page with that label. Also check that your robots.txt file exists, points search engines to the correct sitemap, and doesn’t accidentally block sections you want crawled.

Recheck the logic whenever you add a new page type or change how pages are generated.

You can also use Ahrefs’ Site Audit to compare the URLs in your sitemap against indexability signals and catch pages that shouldn’t be there.

For instance, this report can help you track indexable pages that aren’t in your sitemap (and should be) and noindex pages that shouldn’t be in the sitemap but are.

Some static-site frameworks include tools for resizing, compressing, and serving images more efficiently. But this is not universal. For example, Jekyll copies image files as they are by default, without automatically resizing, compressing, or converting them. To get those image optimizations with Jekyll, you’ll need a plugin, an image CDN, or a separate image-processing step before you publish.

Even when a framework does have built-in image tools, they generally work only when you add images through the framework’s image pipeline.

For example, Next.js provides an <Image> component through next/image that automatically handles things like responsive sizing, optimization, lazy loading, and serving modern image formats. If you use a regular HTML <img> tag instead, you have to handle those optimizations yourself.

If you drop a raw image directly into the site, it can bypass that process entirely.

You can end up publishing an image file that is much larger than it needs to be, which can slow down page loads (especially on mobile). Or you might publish an image without alt text, making it less accessible to people using screen readers and giving search engines less context about what the image shows. Because the site can still build successfully, neither problem is guaranteed to be caught before you publish.

That’s what makes this easy to miss, especially on vibe-coded sites. The page can look completely fine in a preview while still loading unnecessarily large images or incomplete image markup.

Use your framework’s image component or optimization pipeline consistently rather than dropping raw files straight into pages. Before publishing, check for oversized images and missing or blank alt text.

You can also crawl the site with Ahrefs’ Site Audit and check for issues like large image files, missing alt text, and other image-related SEO problems.

There is also a dedicated Images report that you can use to dig deeper into specific image issues:

On static sites, titles, meta descriptions, canonical tags, and schema are often generated from shared templates. That makes them efficient to manage, but it also means one bad default can affect hundreds of pages at once.

For example, adding your brand name automatically to every title could push a whole set of page titles beyond the length you intended.

The same applies to schema. If the template uses the wrong type, misses required properties, or structures relationships incorrectly, that mistake gets reproduced everywhere the template is used.

You can define a pattern once, such as adding the site name to every page title, and apply it across an entire content type. The difference is that Yoast gives you an SEO-specific interface for managing those rules.

On a static site, you may be building the same logic directly into your templates.

For example, Next.js lets you define a title template once in a shared layout and apply it across multiple pages. That’s convenient, but it also means a bad default can spread just as quickly.

Vibe coding can make this easier to miss. An AI-generated template may produce metadata or basic schema that looks reasonable without necessarily matching the page type or structure you actually need.

Define the metadata and schema requirements for each page type before building the template. Then test multiple pages that use it, not just one example, whenever you make a change.

Ahrefs’ Site Audit can also help surface issues with titles, meta descriptions, canonical tags, and structured data across the site.

A page can look like a 404 to a user while still returning a 200 OK status to search engines.

The page visibly showed a “404 — Page not found” message, but Chrome DevTools showed the request returning a 200 status. Google would treat this as a soft 404 because the page says it doesn’t exist while the server reports a successful response.

This can happen when 404 handling hasn’t been configured properly at the framework or hosting level. On Deltener’s Nuxt setup, the issue came from a generated 200.html SPA fallback being served for unknown routes.

The tricky part is that you won’t necessarily spot the same problem on your site just by looking at your pages. Look for when the design says “Page not found” while the underlying HTTP response says everything is fine.

Create a proper 404 page, then test a few URLs you know don’t exist and check the actual HTTP response code. They should return 404, not just display a 404-looking page.

Ahrefs’ Site Audit can also surface URLs returning unexpected status codes, including soft 404s and broken internal links, so you can catch cases that aren’t obvious from browsing the site manually.

Static sites can end up with inconsistent internal links, especially when different templates or AI-generated components build URLs slightly differently.

For example, some links might point to /about, while others point to /about/. You may also end up mixing relative URLs like ../about/ with absolute URLs like https://example.com/about/.

None of these formats is inherently wrong, but problems arise when they don’t match the URL convention you’ve chosen for the site.

These problems can happen even to experienced teams. When we migrated our blog to a new website framework, a misconfigured internal linking rule meant we were nofollowing all of our internal links—effectively telling Google to ignore them. Not ideal:

These issues can create unnecessary redirects, send crawlers through multiple URL versions, and make it harder to keep internal linking signals focused on each page’s canonical version. This is especially easy to introduce on vibe-coded sites, where AI-generated components may use different URL formats unless you explicitly tell the system which convention to follow.

Pick one URL format and use it consistently across templates, navigation, breadcrumbs, and in-content links.

Where possible, define that format once in a shared link component or helper rather than manually typing URLs throughout the site.

Then crawl the site to check for internal links that point to redirects or non-canonical URL versions. Ahrefs’ Site Audit can flag pages linking to redirects:

While the Site Structure report can help you inspect how URLs are organized by folder and link depth.

Static sites have a reputation for being fast, but static generation alone doesn’t guarantee good performance.

A site can still:

These problems can slow rendering and interactivity even when the HTML itself is generated ahead of time.

Vibe-coded sites are especially worth checking.

AI can keep adding scripts, libraries, animations, and components without necessarily considering their cumulative performance cost. A page may look polished in preview while getting heavier with every iteration.

Check the technical decisions behind the build, including:

Then test the finished site rather than assuming a static build is fast. Use PageSpeed Insights to check Core Web Vitals such as LCP, INP, and CLS, and crawl the site to find performance problems across multiple pages.

You can also check Ahrefs’ Site Audit for specific reports on JavaScript and CSS errors:

Moving from a CMS to a static site can introduce SEO problems even when the new pages look identical.

That’s because a website migration often removes more than the CMS interface. You can also lose redirects, sitemap rules, metadata logic, schema, internal linking behavior, and other SEO settings that were previously handled in the background.

One of the biggest risks is URL changes.

If an old URL disappears without a proper 301 redirect to its replacement, any links and ranking signals pointing to that page may be lost.

You can easily check this with the Ahrefs SEO toolbar. Here’s an example from our recent international blog migration, moving from one subfolder structure to another:

It’s also easy to miss things like legacy canonicals, outdated sitemap entries, or stale assets being served from a build or cache.

Treat the move as a full SEO migration, not just a redesign. Before launch:

A static migration can absolutely work well, but don’t assume the new framework will recreate everything your old CMS was quietly doing for you.

There isn’t one static framework that’s inherently “best for SEO.”

Astro, Next.js, Gatsby, Hugo, Jekyll, and similar frameworks can all support strong SEO, but the amount of work required varies depending on what you need to build. Things like canonicals, Open Graph tags, schema, sitemap rules, and noindex handling still need to be configured rather than assumed.

Image handling is one area where frameworks differ more noticeably.

Some, like Astro, have stronger built-in image tooling, while others leave more of the optimization work to you. But for metadata, schema, canonicals, and sitemap logic, the bigger difference usually comes down to how well you configure the framework rather than which one you choose.

So instead of asking “Which framework is best for SEO?”, ask:

The right choice depends on the site you’re building and how much technical control you actually need.

As Pedro puts it:

That’s probably the more useful decision framework. A small site with a handful of pages and infrequent updates may be a great fit for a static setup. A large publishing operation with complex workflows may not be.

Static sites can give you more control, fewer dependencies, and less reliance on plugins. But that control comes with more responsibility.

A traditional CMS hides a lot of SEO plumbing behind plugins and defaults. With a static or vibe-coded site, you’re more likely to own that plumbing yourself, from canonicals and sitemaps to redirects, schema, performance, and status codes.

Vibe coding makes the build process faster, but it doesn’t remove the need to understand what good technical SEO looks like.