Skip to main content

robots.txt, static files and redirects

  • August 17, 2025
  • 3 replies
  • 255 views

sochnev

Current: Site > Settings > General > Custom code

Add section: Site > Settings > General > Non-page requests

 

So I could add

  1. Pairs of request and static content:
    1. robots.txt (and add static text content)
    2. some-verification-file-name.txt (and add static text content)
    3. sitemap.xml (and add static/dynamic content)
  2. Redirects
    1. request (and redirect url)

This should cover a wide range or common scenarios.

 

3 replies

Rafael Diaz
  • New Member
  • December 24, 2025

How is this not getting more likes? Give it a thumbs up!

Definitely a useful feature, considering robots.txt is not even being auto generated, so SEO with Google tools get affected.


Webb Qin
  • New Member
  • January 15, 2026

Hello Figma Product Team,

I’m writing as a long-time Figma user who is actively trying to use Figma not only for design, but as part of a real website publishing and go-to-market workflow.

This feedback is specifically about SEO and Google indexing, not language or localization.

1. Make-generated websites are effectively not indexable by Google

Make is extremely productive and intuitive.
However, from an SEO and discovery standpoint, Make-published sites are fundamentally unusable:

  • No reliable server-side rendered HTML

  • No control over robots.txt

  • No support for sitemap.xml

  • No canonical or metadata control

  • URLs are not consistently indexable

As a result, Make websites are practically invisible to Google Search, regardless of content quality.

This makes Make unsuitable for:

  • Company homepages

  • Landing pages

  • Marketing sites

  • Startup MVPs that rely on organic discovery

2. There is no upgrade path from Make to an SEO-capable solution inside Figma

From a user’s perspective, the expected workflow is:

Design → Make → Publish → Grow → Improve SEO

But today:

  • Once a site is built with Make, there is no migration path to Figma Sites

  • Users are forced to abandon their work and move outside the Figma ecosystem

This creates a dead end rather than a growth path.

3. Figma Sites does not currently solve core SEO requirements either

Even if migration were possible, Figma Sites still lacks essential SEO infrastructure:

  • No proper sitemap generation

  • No robots.txt control

  • Limited metadata management

  • Not designed for search-driven traffic

Sites currently feels closer to a presentation layer than a true publishing platform.

What would significantly improve the situation

From a product standpoint, any one of the following would unlock massive value:

  1. Make output that is SEO-capable
    (indexable HTML, sitemap, robots, metadata)

  2. A supported migration path:
    Make → Figma Sites

  3. Clear positioning and documentation:

    • Is Make intended for real websites or demos only?

    • Is Sites intended to support SEO-driven use cases?

Right now, Figma’s design tools are best-in-class, but the publishing story stops just before the most critical step: being discoverable on the web.

I’m sharing this feedback because I genuinely want to keep my workflow inside Figma.
At the moment, SEO limitations are the single biggest reason forcing me to look elsewhere.

Thank you for taking the time to read this, and I hope it reaches the appropriate product team.


Tal Eilon
  • New Member
  • March 20, 2026

Fixed!!! Used Openclaw and migrated the entire website over:

 

🎉 https://beta.xxxacmexxx.com is live! (domain name changed for security reasons)

Here's what went down:

  • ✅ Downloaded your Figma Make source from Dropbox
  • ✅ Pulled all 38 Figma image assets via the API
  • ✅ Patched the source to resolve the assets locally
  • ✅ Built the React/Vite app
  • ✅ Created DNS record on Cloudflare
  • ✅ Set up Nginx on Miami with SSL (Let's Encrypt, auto-renews)
  • ✅ Deployed — live at https://beta.xxxacmexxx.com

Go check it out! 🌊

 

Here's the full breakdown:

1. Downloaded your zip from Dropbox
Grabbed the 41MB file you shared and extracted it locally.

2. Discovered it's a React/TypeScript app (Vite + shadcn/ui)
This isn't a static HTML site — it's a modern JavaScript app that needs to be compiled before it can be served. The Figma Make export generates real React code.

3. Hit the first problem: broken image imports
The exported code had references like figma:asset/abc123.png — those are internal Figma identifiers, not real files. Figma Make assumes you'll publish through Figma's own hosting, so it doesn't include the actual images in the zip.

4. Used the Figma REST API to fetch the images
With your personal access token + file ID, I called Figma's API to get the real S3 download URLs for every image asset in the file, then downloaded all 38 of them.

5. Patched the source code
Changed all figma:asset/... references to local paths, and added a Vite alias so the build system could find them. (Vite is picky — /absolute/paths in imports break the build, so I had to teach it where to look.)

6. Built the app
Ran npm install + npm run build, which compiled all the TypeScript/JSX into plain HTML/CSS/JS — the actual files a browser can serve.

7. Set up the server on Miami

  • Created a DNS A record on Cloudflare pointing beta.acme.com → Miami VPS
  • Installed and configured Nginx to serve the site
  • Got an SSL certificate from Let's Encrypt (so it's HTTPS)
  • Copied the built files over via rsync
  • Fixed file permissions (rsync preserved your Mac's ownership, which Nginx couldn't read)

8. Debugged Cloudflare's 404
Cloudflare was returning its own 404 because Miami didn't have SSL — Cloudflare tries to connect to your server over HTTPS by default and bailed when port 443 wasn't listening. Adding the cert fixed it.

End result: every time someone hits beta.acme.com, Cloudflare proxies the request → Nginx on Miami → serves your compiled React app. 💧