Flutter SEO: why a Flutter web app is hard to index and the split Flutter's own docs recommend

Flutter SEO starts with one sentence from Flutter's own documentation: Flutter web "prioritizes performance, fidelity, and consistency", so its "output doesn't align with what search engines need to properly index". The answer is a split. Build the pages you want found, such as the landing page, marketing pages, help content and blog, as ordinary HTML, either with any website tool or with Jaspr if your team wants to stay in Dart. Keep Flutter for the app behind them. If parts of the Flutter app itself must be found, switch to path URLs, set titles and descriptions per route, return real status codes, and turn on semantics, in that order.

This page explains why Flutter behaves this way, what the docs recommend, and the checklist for the routes you cannot move out of the app. All quotes were read on 22 October 2026, from documentation that states it reflects Flutter 3.47.

What Flutter's own documentation says about SEO

The Flutter web FAQ has a section titled "Search Engine Optimization (SEO)". It says Flutter is "geared towards dynamic application experiences" and that web support "is no exception". It then gives two routes for content that is "static or document-like":

• Jaspr, a community package, "if you want to use Dart but want a more traditional DOM-based website". The FAQ adds that Jaspr "makes SEO work in the same way a traditional website would".
• Plain HTML, by "separating your primary application experience (created in Flutter), from your landing page, marketing content, and help content (created using search engine optimized HTML)".

The "Web support for Flutter" page says the same thing in other words: text-rich, flow-based, static content "such as blog articles" suits the document-centric model of the web better than an app framework. It also notes that the Dart documentation, the Flutter documentation and the Flutter marketing websites were moved to Jaspr. The Flutter team builds its own documentation and marketing sites with Jaspr, not with Flutter web. That is the clearest guidance you will get.

Why a Flutter web page gives a search engine little to read

Flutter draws its interface itself. The Flutter accessibility guide puts it plainly: Flutter "renders its UI on a single canvas". Text drawn on a canvas is pixels, not HTML text, so there are no headings, paragraphs or links in the page for a crawler to parse.

We checked this on Wonderous, the demo app the Flutter docs point to, on 22 October 2026. Its first HTML response was 13,975 bytes. Once scripts and styles were removed, it held one visible word, "Wonderous", and no <a href> links at all. Everything else arrives through JavaScript after the Flutter engine starts.

Google can render JavaScript. Its JavaScript SEO guide describes three phases, crawling, rendering and indexing, and pages wait in a queue for rendering. The same guide says "server-side or pre-rendering is still a great idea because it makes your website faster for users and crawlers, and not all bots can run JavaScript". It also says Google "can only discover your links if they are <a> HTML elements with an href attribute". A canvas app gives it neither readable text in the first response nor normal links.

The split: which part to build with what

Part of the product	Needs to rank?	Build it with
Home and landing pages	Yes	HTML, any site builder, or Jaspr
Feature and pricing pages	Yes	HTML or Jaspr
Blog, guides, help centre	Yes	HTML, a docs tool, or Jaspr
Logged-in app, dashboards, editors	No	Flutter web
Public app screens people search for, such as a listing	Sometimes	Prefer HTML; if it stays in Flutter, follow the checklist below

A common layout is the marketing site at the root of the domain and the Flutter app on a subdomain or a subfolder such as /app. The Flutter docs cover hosting the app at a non-root location: you change the base href tag in the app's index.html to the path where the app lives.

Jaspr is worth a look if your team writes Dart and would rather not run a second stack. Its site describes components that "look very similar to Flutter widgets" but render "actual HTML and CSS". It is a separate framework, not a Flutter mode, so you write the marketing pages again rather than reuse Flutter widgets as they are.

If parts of the Flutter app must be found: the checklist

1. Use path URLs, not hash URLs

Flutter web uses hash URLs by default, so a screen lives at an address like example.com/#/products. Google's guide says not to use fragments to load different content, because Googlebot "can't reliably resolve" those URLs, and to use the History API instead. Flutter supports this through usePathUrlStrategy from the flutter_web_plugins library, which you add as an SDK dependency in pubspec.yaml:

import 'package:flutter_web_plugins/url_strategy.dart'; void main() { usePathUrlStrategy(); runApp(ExampleApp());
}

Path URLs need your web server to send every route to index.html. On Firebase Hosting, the docs say to choose "Configure as a single-page app" when you set up the project.

2. Return a real status for missing routes

That rewrite has a side effect. Every unknown path now returns index.html with a 200 status, so a typo URL looks like a real page. Google's guide asks for meaningful status codes, such as 404 for a page that does not exist. Where the server cannot know which routes are valid, Google's guide shows two client-side options: redirect to a URL that returns a 404, or add a robots meta tag with noindex from JavaScript.

3. Set a title and description for each route

Google's guide confirms you can use JavaScript to set or change the title element and the meta description. Give each public route its own. Set the canonical URL in the original HTML where you can, and if you set it with JavaScript, Google asks that it match the value in the original HTML.

4. Make links real links

Navigation drawn on a canvas is not an <a> element. For any public route you want crawled, list it in an XML sitemap and link to it from your HTML marketing pages, so discovery does not depend on the app.

5. Turn on semantics for accessibility

Flutter translates its internal semantics tree into an accessible HTML structure, but for performance reasons this "is not on by default". You can turn it on in code with SemanticsBinding.instance.ensureSemantics() when running on the web, and use the Semantics widget with SemanticsRole to give custom widgets roles such as list or heading, which Flutter maps to ARIA roles. Do this for screen reader users first. Treat it as a fix for accessibility, not a replacement for real HTML pages.

The same rendering choices come up with other client-side frameworks. Our Angular SEO guide covers the route-by-route version of this decision for a framework that can render on the server.

Questions about Flutter SEO

Is Flutter good for SEO?

Flutter is built for apps, and its own docs say its web output does not match what search engines need. Use it for the app, and build the pages you want found in HTML or Jaspr.

Can Google index a Flutter web app at all?

Google renders JavaScript, but Flutter's docs say the UI is drawn on a single canvas and that the accessible HTML layer is off by default. The first response holds almost no text and no normal links, which is why Flutter recommends HTML for content that must rank.

What is Jaspr?

Jaspr is a free, open source framework for building websites in Dart. Its components look like Flutter widgets but output real HTML and CSS. The Dart and Flutter documentation sites run on it.

Should a Flutter mobile app have a website at all?

Yes, if you want people to find it through search. The questions people type into a search engine are answered by web pages, and a small HTML site with one page per use case gives search engines and assistants something to read.

Do hash URLs hurt Flutter SEO?

Yes. Google says it cannot reliably resolve content loaded through fragments. Switch to path URLs with usePathUrlStrategy and configure the server to rewrite routes to index.html.

What an assistant reads when it looks at your Flutter product

Search engines are no longer the only reader. When someone asks ChatGPT or Perplexity which app to use for a job, the answer is built from pages those systems fetched and read, and a reader that does not run JavaScript sees a Flutter page the way our Wonderous check did: a title and almost nothing else. The HTML pages you build for search are the same pages an assistant can quote, so the split above serves both. If you want to know whether assistants actually name your app for the questions your buyers ask, AI Knows Us asks them and records which products each answer names and which pages it drew on.