Why animations break during conversion in the first place
Converting a live page into a WordPress theme means moving CSS and JavaScript from a static or CMS-rendered context into WordPress's template and enqueue system. CSS keyframe animations and transitions defined purely in stylesheets tend to survive this move intact, but anything relying on JavaScript, IntersectionObserver-based scroll triggers, GSAP timelines, AOS.js, or class toggling on scroll, breaks if the script does not load in the right order or at all.
The other common cause is CSS specificity or cascade order changing because WordPress core, plugins, or the active theme's own reset styles get enqueued after your animation CSS, overriding transition and transform properties you depended on.
Preserving stylesheet load order with wp_enqueue_style
Register and enqueue your stylesheets inside functions.php using wp_enqueue_style(), specifying dependencies so WordPress loads them in the correct sequence rather than relying on the order of your handle calls alone. If your original CSS animation file depends on variables or resets defined in a base stylesheet, declare that base stylesheet as a dependency.
- In functions.php, hook into wp_enqueue_scripts.
- Enqueue your base/reset stylesheet first with wp_enqueue_style('theme-base', ...).
- Enqueue the animation stylesheet with the base as a dependency: wp_enqueue_style('theme-animations', get_template_directory_uri() . '/css/animations.css', array('theme-base'), '1.0.0').
- Confirm in the page source that both link tags appear in the expected order inside the head.
Enqueuing animation JavaScript correctly
Scroll-triggered animations almost always depend on a JS library that needs to run after the DOM is ready and often after jQuery if the original code used it. Enqueue these with wp_enqueue_script(), setting the jQuery dependency explicitly and loading in the footer so the DOM elements being animated already exist when the script runs.
A common failure is a theme missing the wp_footer() call in footer.php entirely; WordPress and plugins hook scripts into wp_footer, so if that call is absent, all footer-enqueued scripts, including your animation library, simply never print to the page and nothing errors visibly in the browser console.
Handling libraries like AOS.js or GSAP after conversion
If the original site used AOS.js for scroll animations, you need both the library file and its own initialization call, typically AOS.init(), to survive the move. Enqueue the AOS script and stylesheet, then enqueue a small custom script as a dependent that calls AOS.init() after the library loads, since simply copying the HTML data-aos attributes does nothing without the library actually initializing.
For GSAP-based animations bound to specific selectors, confirm those selectors still match the converted markup; WordPress template functions sometimes wrap content in additional divs (like entry-content) that can shift descendant selectors relying on direct child relationships.
Testing that animations still fire after the move
Open the converted page with browser devtools open, check the Network tab to confirm every animation-related CSS and JS file returns 200 rather than 404, and check the Console tab for JavaScript errors, which frequently reveal a library trying to run before its dependency has loaded.
Scroll through the full page slowly and compare directly against the original live URL side by side; animations that only trigger near the bottom of long pages are easy to miss if you only check the top of the page after conversion.
Where a manual conversion tends to lose fidelity
Manually rebuilding a page as a theme by copying HTML and CSS by hand is where animation fidelity is most often lost, since it is easy to drop a script tag, change its position in the DOM, or forget an initialization call during the rewrite. Themify captures the page's CSS and JavaScript as-is and preserves the enqueue order automatically as part of the conversion, which is specifically why animation-heavy sites are one of the more reliable use cases for it compared to a fully manual rebuild.
If you do rebuild by hand for more control over the final code, budget real testing time for animations specifically, since they are the feature most likely to silently regress compared to static layout or typography, which fail loudly and obviously if broken.
Frequently asked questions
- Why do my scroll animations stop working after converting a site to a WordPress theme?
- Usually the JavaScript library driving them either failed to enqueue, is missing its initialization call, or wp_footer() is absent from footer.php so footer scripts never print.
- Do pure CSS keyframe animations survive conversion better than JS-based ones?
- Yes, animations defined entirely in CSS with @keyframes generally survive as long as the stylesheet itself loads, since they do not depend on a separate script executing at the right time.
- Should animation CSS go in the main stylesheet or a separate file?
- Either works, but a separate file enqueued with an explicit dependency on your base stylesheet makes load order predictable and easier to debug than one large combined file.
- How do I check if a script is missing because of wp_footer?
- View page source and search for your script's filename; if it is enqueued to load in the footer but does not appear anywhere in the HTML, footer.php is likely missing the wp_footer() call.