MotionKit

MotionKit is a different kind of WordPress animation product. Instead of putting every control inside Elementor, Bricks, or wp-admin, it uses a hosted visual editor with WordPress-side plugins that connect the site and run published animations. The current setup guide documents two WordPress plugins: the MotionKit account plugin and the MotionKit Connector. You connect the site, open the real page in MotionKit, target an element by a stable CSS class, build the animation on a timeline, preview it, and publish the configuration back to WordPress.

Quick take

The workflow feels closer to a dedicated motion-design tool than a normal WordPress addon. That is the main reason to consider it. You get one animation workspace across Elementor, Bricks, Gutenberg, Divi, Breakdance, and other supported builders instead of learning a different motion panel for every stack.

The trade-off is that the editing experience is account-connected and hosted. If your team wants every design control to live inside the WordPress admin or inside the page builder, MotionKit will feel less native. If you care more about having one reusable GSAP workflow across different builders, the separation is useful.

Best fit: MotionKit makes the most sense for WordPress freelancers and agencies that want one visual animation workflow across Elementor, Bricks, Gutenberg, Divi, Breakdance, and other builders. A different option will usually make more sense for simple sites that only need basic entrance effects or teams that require all design tooling to remain fully self-hosted inside WordPress.

The connector-plus-editor model is the biggest decision

The current setup guide uses two WordPress plugins with different jobs. The MotionKit account plugin adds the admin connection flow and account-facing controls, while the MotionKit Connector stores and runs published animation data on the site. After both are active, you link the site to your MotionKit account, open a real page in the hosted editor, target the element you want to animate, build the effect, save it, and publish. The editor works against the live front-end layout instead of an abstract canvas.

I like that approach for mixed-builder agencies. A Bricks project and an Elementor project can use the same animation concepts, timeline, presets, and naming conventions. You are not buying into an Elementor-only or Bricks-only motion system.

The part I would document carefully is handoff. The animation configuration belongs to an account-connected workflow, so a client handover should include who owns the MotionKit account, which site slot is being used, which pages contain MotionKit animations, and how the connector is managed. That is not a flaw, but it is operationally different from handing over a self-contained plugin.

The timeline is the part that makes the workflow feel serious

A lot of WordPress animation tools are really collections of isolated controls: choose an entrance effect, set duration, add a delay, repeat. MotionKit becomes more useful when several elements need to work together. The timeline gives you a visual way to see sequence, overlap, delay, easing, and trigger behavior rather than scattering those settings across individual widgets.

The current feature set includes ScrollTrigger controls, scrub and pin behavior, parallax, text effects, SplitText-style sequences, SVG and image effects, MotionPath-style movement, smooth scrolling, preloaders, responsive settings, page transitions, presets, and reusable configurations. MotionKit 1.2.0 added visual scroll start/end markers, scrub and pin controls; 1.3.0 improved timeline scrubbing and added reusable animation libraries plus JSON import/export.

That progression matters. It shows the product is not just adding more presets; it is building the management layer around those animations.

Version 1.5.0 changes the free story

The September 22 release added a second animation engine that can run without GSAP and expanded the free preset catalogue. MotionKit now separates free animation families from GSAP-dependent effects so the editor only offers an effect where the connected site can actually run it.

That is a sensible design decision. A free user can work with fades, slides, zooms, blur, attention effects, split text, image, button, loop, and hover-style presets without the product pretending every advanced GSAP feature is available. The release also added search and load-more in the free catalogue, better controls for free scroll/hover animations, and a requirement that an animation be saved before it can be published.

From a workflow perspective, that last point is important. Publishing and saving being separate states is much safer than letting a half-configured animation go live because the editor assumed the latest preview was final.

The free plan is useful enough to evaluate on a real site

The current pricing table gives the free plan one connected site, two pages, and up to 15 active animations. It includes the visual editor, timeline, ScrollTrigger controls, limited presets, preloader, smooth scrolling, direct WordPress publishing, and responsive controls.

That is enough to decide whether you like the editor before paying. It is much better than a demo that only lets you watch preset previews.

As of this review, the live pricing page is clear about the current free allowance: one connected site, two pages, and 15 active animations. Because MotionKit is still in its launch window, I would still recheck the checkout or account dashboard before budgeting a client rollout, especially for lifetime promotions and site limits.

Paid plans are really about scale and reuse

The annual Starter plan is currently $39 per year for one site. Freelancer is $60 per year for five sites, Agency is $120 for 100 sites, and Studio is $144 for 500 sites, with collaboration and reuse features expanding at the higher tiers. MotionKit is also running one-time lifetime licenses during the launch window, with an early-bird promotion from September 23 to 29.

The reason I would move beyond Starter is not simply “more animations.” Freelancer-level features such as reusable animation libraries, JSON import/export, and cross-project reuse change the agency workflow. Agency and Studio then add larger site capacity and collaboration/high-volume features.

I would not copy the temporary lifetime discount into an agency budget without rechecking checkout. MotionKit explicitly says founder pricing is launch-window pricing, so it is expected to change.

Reusable animation libraries are the most interesting agency feature

MotionKit 1.3.0 added the ability to save finished animations and use them on another connected site. This is where the product can move from “animation editor” to “motion system.” An agency can standardize a few interaction patterns and reuse them without rebuilding the timeline every time.

I would keep that library intentionally small. Naming matters more than the number of presets. “SaaS hero reveal,” “case-study image scrub,” or “CTA hover treatment” is more useful to a team than a folder of effects called “cool intro 1,” “cool intro 2,” and “new final animation.” Reusability only saves time when the system is understandable by someone other than the person who created it.

Recent releases show attention to publishing and reliability

MotionKit 1.4.0 added animation status, share links, bulk publishing, publish-latest-changes, folders, a DevTools panel, improved page transitions, and better account/session handling. The same release also split some front-end bundles so preloader and page-transition code only ship where needed.

Version 1.5.0 continues that reliability work. The changelog includes fixes for unsaved publishing, failed save acknowledgements, free scroll/hover behavior, deleted animations continuing to run, trigger conflicts, page-transition states, connection callbacks, and several animation presets. It also includes security work around license keys.

Those are the kinds of changes I want to see in a visual editor. The hard part of an animation platform is not adding another effect; it is keeping save, preview, publish, connection, and rollback behavior predictable.

Performance still depends on what you build

MotionKit’s architecture is designed so the connector and animation runtime are used where animations are actually present, and recent releases split bundles more aggressively. That is the right direction. But no animation platform can protect a page from an overambitious design.

If I build a long page with several pinned sections, large video, continuous scroll scrubbing, complex SVG effects, filters, and multiple simultaneous timelines, the page can still become expensive. I would test the finished production page on mid-range mobile hardware, not only a desktop Lighthouse run. I would also test with the real analytics, consent, chat, ad, and marketing scripts enabled.

Selector stability is the maintenance risk I would watch

Because MotionKit targets elements on the real page, the reliability of a published animation depends on the selector or class continuing to identify the intended element. If a builder redesign changes class names, markup, or component structure, the animation may need to be retargeted.

For agency sites I would prefer deliberate CSS classes for animated components rather than fragile selectors based on generated structure. I would also document which selectors are used by important page transitions or scroll interactions before a large redesign.

Accessibility should limit how much motion you add

The fact that MotionKit makes advanced motion easier does not mean every section should move. I would check reduced-motion behavior, keyboard order, focus behavior, and whether the content still makes sense when an animation is removed. Page transitions and pinned sections deserve extra attention because they can affect navigation and reading order more than a decorative reveal.

The best implementation is not the one with the most timelines. It is the one where motion explains hierarchy or gives feedback without getting between the visitor and the content.

How MotionKit differs from Animation Addons and BricksFly

Animation Addons and BricksFly are builder-specific toolkits. They combine motion with widgets, elements, templates, and extensions. MotionKit is narrower but more portable. It is trying to become the animation workspace, not the page-builder addon.

If I already like my existing builder stack and only want a stronger motion workflow, MotionKit is easier to justify. If I also need dozens of Elementor widgets or a full Bricks template/element library, one of the builder-specific products may consolidate more subscriptions.

What I would verify before putting it on a client site

• Confirm the exact plan limits in the live account/checkout while launch pricing is still changing.
• Use stable, deliberate CSS classes for important animation targets.
• Test connect, disconnect, republish, and account-transfer behavior on staging.
• Document which pages depend on MotionKit and who owns the account.
• Test page transitions, smooth scrolling, pinning, and scrubbed effects on mobile hardware.
• Check reduced-motion behavior and keyboard navigation.
• Keep reusable animation names and folders understandable for the whole team.

Who should consider MotionKit?

I would shortlist MotionKit for agencies, freelancers, and designers working across more than one WordPress builder who want one visual GSAP-style workflow and a reusable motion library. I would skip it for simple brochure sites, teams that only need basic entrance effects, or organizations that require all design tooling and editing to remain fully self-hosted inside WordPress.

FAQs