# What happens to embeds (YouTube, maps, X) after migration? > When you migrate off WordPress, most of your embeds keep working, because a YouTube video, a Google Map, or a social post embed is standard code that renders on any platform, so it comes across with the content. The part that needs attention is WordPress-specific convenience: WordPress lets you paste a bare URL and auto-converts it into an embed through a feature called oEmbed, and that shortcut does not exist on other platforms, so those bare-URL embeds are rebuilt as the standard embed snippet the provider gives you. The same applies to any embed added by a plugin or a shortcode, which becomes proper embed code on the new site. The result looks identical to visitors: the video plays, the map shows, the post renders. WPBuildAI rebuilds every embed as standard provider code, converting WordPress oEmbed and plugin embeds into snippets that render anywhere, so nothing goes blank after the move. Source: https://wpbuildai.com/what-happens-to-embeds-after-migration/ By lawrence-arya ยท 2026-06-10 --- When you migrate off WordPress, most of your embeds keep working, because a YouTube video, a Google Map, or a social post embed is standard code that renders on any platform, so it comes across with the content. The part that needs attention is WordPress-specific convenience: WordPress lets you paste a bare URL and auto-converts it into an embed through a feature called oEmbed, and that shortcut does not exist on other platforms, so those bare-URL embeds are rebuilt as the standard embed snippet the provider gives you. The same applies to any embed added by a plugin or a shortcode, which becomes proper embed code on the new site. The result looks identical to visitors: the video plays, the map shows, the post renders. WPBuildAI rebuilds every embed as standard provider code, converting WordPress oEmbed and plugin embeds into snippets that render anywhere, so nothing goes blank after the move. ## Most embeds are just code, so they travel The reassuring part first: a standard embed is portable by nature. When you embed a YouTube video or a Google Map, what sits in the page is a snippet of standard HTML that points at the provider, and that snippet renders the same whether the page is served by WordPress or anything else. So those embeds come across with the content and keep working, because nothing about them depends on WordPress. This is the general case, and it is why migrating a page full of ordinary video and map embeds is usually a non-event: the code is the code, and it runs anywhere. The exceptions are specific and identifiable, which is what the rest of this comes down to. ## The oEmbed shortcut is the real exception The one WordPress-specific behavior to know is oEmbed. WordPress supports the [oEmbed specification](https://oembed.com/), which means you can paste a bare URL, like a plain YouTube or map link, on its own line, and WordPress silently turns it into a full embed for you. It is a convenience, but it hides the fact that no real embed code was ever stored; WordPress generated it on the fly. Other platforms do not do this, so a bare URL that looked like a video on WordPress becomes plain text, or a dead link, after migration. This is closely related to how [WordPress shortcodes behave in a migration](/what-happens-to-wordpress-shortcodes-after-migration): both are WordPress conveniences that need converting into standard output. The fix is simply to rebuild each one as the provider's real embed snippet. ## Plugin and shortcode embeds are rebuilt too Beyond oEmbed, some embeds were added by plugins or shortcodes, and those do not survive on their own because the plugin does not exist on the new site. A social feed widget, a form embed, a testimonial slider, or a map added through a plugin all fall into this group. Each is rebuilt using either the provider's own embed code or the new platform's equivalent, which is part of why a rebuild is genuine reconstruction rather than a raw copy, and why [a builder does not simply import everything](/will-an-ai-website-builder-import-my-existing-content) untouched. The visible outcome is unchanged, the feed shows, the form works, but the mechanism moves from a WordPress plugin to standard code the page includes directly, which is simpler and more portable going forward. ## Check for embeds that turned into broken links After launch, the practical risk is an embed that quietly became a broken link or a blank space. A bare-URL oEmbed that was not converted shows as plain text; a plugin embed that was not rebuilt shows nothing. So a migration is a good moment to scan for these, in the same pass as you [fix broken links](/fix-broken-links-wordpress-after-migration), and it fits the general discipline of a [careful site move](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes). Spot-check the pages you know contained videos, maps, or feeds, and confirm each renders. Because embeds are visual, a quick look at the key pages catches almost everything, and it is far better to find a blank video box yourself than to hear about it from a visitor. ## Mind the weight of third-party embeds A migration is also a chance to be deliberate about embed weight. Third-party embeds pull in the provider's scripts, and a page stacked with many of them is heavier, which is true on any platform, not a migration problem, but worth addressing while you rebuild. Since images and third-party resources are already the bulk of page weight, as [Web Almanac 2024](https://almanac.httparchive.org/en/2024/) shows, a clean rebuild can load embeds more efficiently, for instance only when they scroll into view, which helps your [Core Web Vitals](https://web.dev/articles/vitals). Keep the embeds that earn their place, rebuild them as standard code, and avoid piling on heavy widgets you do not need. The move is a good time to tidy, not just to reproduce. ## Steps to handle embeds in a migration 1. **List the pages with embeds:** videos, maps, social posts, feeds, forms. 2. **Identify oEmbed bare URLs** that WordPress auto-converted, and mark them for rebuilding. 3. **Rebuild each embed** as the provider's standard snippet or the platform's block. 4. **Replace plugin embeds** with standard code, since the plugin will not exist. 5. **Spot-check the pages** after launch to confirm each embed renders. 6. **Load heavy embeds efficiently** so they do not drag page experience. ## Worked example: a bare-URL video that went to text Consider a tutorial site whose posts embedded YouTube videos, many added the WordPress way by pasting the bare video URL on its own line. During the rebuild, the standard iframe embeds carried across fine, but the bare-URL ones, which had relied on oEmbed, came through as plain text links because the new platform did not auto-convert them. The team identified those posts, replaced each bare URL with YouTube's standard embed snippet, and spot-checked the pages. Every video played again exactly as before. The only work was converting a WordPress convenience into standard code, and because they knew to look for it, no tutorial shipped with a dead video link where a player should have been. ## Limitation: embeds depend on the provider staying up It is honest to bound this. Rebuilding an embed as standard code makes it portable, but the embed still depends on the third-party provider: if a video is deleted, an account is closed, or a service shuts down, the embed breaks regardless of your platform, and that is outside a migration's control. Deprecated or unusual embed types may also need a modern replacement rather than a like-for-like copy. So treat the migration as faithfully carrying your embeds across as standard code, while accepting that their long-term life depends on the providers behind them, exactly as it did on WordPress. ## Key points When you migrate off WordPress, most embeds keep working, because a standard video, map, or social embed is ordinary code that renders on any platform and travels with the content. The real exceptions are WordPress conveniences: oEmbed, where a pasted bare URL was auto-converted, and plugin or shortcode embeds, which are rebuilt as the provider's standard snippet since the plugin will not exist on the new site. Visitors see no difference once rebuilt, so the work is identifying the WordPress-specific embeds and converting them, then spot-checking the pages after launch for any that turned into text or a blank. Use the move to load heavy embeds efficiently, and remember an embed still relies on its provider staying live. WPBuildAI rebuilds oEmbed and plugin embeds as standard code that renders anywhere, so nothing goes blank after the move. Send your web address for a free analysis. Not affiliated with WordPress, Lovable, Webflow, Shopify, Wix, or Squarespace.