Figma to WordPress

The honest answer: there is no one-click path, and the tools that promise one produce a visual approximation you cannot maintain. What actually gets a design into WordPress is a handoff that converts a picture into a system, and then an implementation of that system as a theme.

The good news is that the handoff is the valuable part regardless of what builds the site.

What the automatic converters really produce

Plugins and services that turn a Figma frame into a WordPress page generally output one of two things: absolutely positioned markup that matches the design pixel for pixel at one width, or a page builder's section structure approximating the layout.

Both look convincing in a screenshot and fail on contact with reality:

• Content of a different length breaks the layout, because the design was pinned rather than laid out.
• Responsiveness is approximated, if it exists at all, and usually at the two or three widths the file contained.
• Nothing is a component. Twenty cards are twenty independent blocks of markup, so changing the card means changing it twenty times.
• Semantics are gone. Headings become styled divs, which costs you accessibility and SEO.
• There is no content model. A blog listing is a picture of a blog listing, not a query.

They have a legitimate use: a fast visual prototype, or a one-off landing page nobody will maintain. For a site, they move work from the build into the maintenance, where it is more expensive.

What the handoff should contain

This is the part worth being demanding about. Ask for these, not for "the Figma link":

A type scale. The actual sizes, weights, line heights and the ratio between them — not eleven arbitrary sizes. Fonts chosen with the constraints in how to choose fonts for a website, including the licence for web use.

A colour palette with roles. surface, text, accent, border — not blue-2. Roles map onto theme settings; names do not, and a palette named by hue cannot be re-themed. See how to choose a website colour palette.

A spacing scale. A small set of steps used consistently, so the build has a system instead of a hundred measured gaps.

Breakpoints and reflow behaviour. Not just a mobile frame — what each component does between the drawn widths. The responsive web design checklist is the list to check the design against.

Every state. This is the most commonly missing item and the most expensive: hover, focus, active, disabled, error, empty and loading, for every interactive element. Focus states in particular are almost never drawn and are not optional.

Real content ranges. The longest plausible headline and the shortest. A design proven only against "Lorem ipsum dolor sit" will break on your actual titles.

Map the design onto WordPress before building

Before any markup, decide what each piece of the design is in WordPress terms:

• Which frames are templates — front page, single post, archive, 404?
• Which repeating elements are query loops rather than static cards?
• What is a template part — header, footer, a reused call to action?
• What is content an editor will change, and what is design they should not?
• Does anything need a custom post type or taxonomy?

Skipping this is what produces sites where the client cannot change anything without a developer, and it is a modelling failure rather than a build failure.

Block theme or page builder

The design does not decide this. Who maintains the site does.

A block theme turns the design system into theme.json — palette, type scale, spacing steps — which is exactly the shape the handoff produced. Editors get constrained, on-brand options; developers get a real system in version control. Start from how to create a WordPress block theme.

A page builder is the right call when a non-technical team will restructure pages regularly and cannot wait for a developer. You accept the storage lock-in described in choosing a page builder.

The comparison in how to judge a WordPress theme applies to a theme you are building too — you are choosing what future-you has to maintain.

Tokens into theme.json

The handoff maps almost directly:

{
  "$schema": "https://schemas.wp.org/trunk/theme.json",
  "version": 3,
  "settings": {
    "color": {
      "palette": [
        { "slug": "surface", "color": "#ffffff", "name": "Surface" },
        { "slug": "text", "color": "#1a1a1a", "name": "Text" },
        { "slug": "accent", "color": "#1f3a5f", "name": "Accent" }
      ],
      "custom": false
    },
    "spacing": {
      "spacingSizes": [
        { "slug": "s", "size": "0.75rem", "name": "Small" },
        { "slug": "m", "size": "1.5rem", "name": "Medium" },
        { "slug": "l", "size": "3rem", "name": "Large" }
      ]
    }
  }
}

Setting "custom": false on colour removes the arbitrary colour picker, so editors cannot introduce off-brand values. That single line preserves more design integrity over a site's life than any amount of pixel matching at launch.

Common mistakes

• Treating the Figma file as the specification. It is a picture of one state at one width.
• Building pages instead of templates, so every new post has to be designed by hand.
• Pixel-matching a design at one viewport and calling it responsive.
• Ignoring focus states, then failing an accessibility review after launch.
• Letting the editor change anything. Unconstrained colour and font pickers undo a design system within months.
• Using a converter for a real site, then paying twice — once for the conversion and once for the rebuild.

Verify against the design

At the end, compare the built site to the file at the drawn widths and between them, with your real content, on a real phone. Then check what the design never showed: a headline twice as long, a post with no featured image, an empty search result, a form in its error state, and the whole thing navigated with a keyboard alone. Those five are where Figma-to-WordPress projects are actually judged.