FNJ / MIGRATION LIBRARY
Your exported site.
Ready for the next change.
From fixing a form to publishing new content: practical checks, platform-specific notes and copyable prompts for your own agent.
Edit with MCP
Connect an agent to FNJ MCP, inspect the correct route, change content and review the draft before publishing.
Framer / Edit with MCP
Edit an exported HTML site with an AI agent
For Framer, distinguish the saved HTML draft from original generated Next.js source. An MCP footer edit affects the saved site; it does not automatically rewrite every React component in the original source ZIP. Select the intended artifact when downloading or exporting to GitHub, then compare that artifact with your approved preview.
Read the guide →Webflow / Edit with MCP
Edit an exported HTML site with an AI agent
Webflow interaction classes and shared components can appear on many captured pages. When changing a footer or section with MCP, list the intended routes and preview a CMS article too. A saved HTML change does not modify a Webflow symbol, component or collection field in the original designer project.
Read the guide →Gamma / Edit with MCP
Edit an exported HTML site with an AI agent
Gamma exports capture the published website's card output. Ask the agent to inspect the correct card and its embedded media before rewriting copy or adding a section. The HTML edit does not update a Gamma deck, workspace permissions or the editable card model in the original account.
Read the guide →systeme.io / Edit with MCP
Edit an exported HTML site with an AI agent
For a systeme.io funnel, specify the exact step and every CTA destination in your agent task. A shared button-label edit must not silently move the payment link or opt-in destination. MCP changes the captured front end; it does not update contact records, email campaigns or the original funnel automation.
Read the guide →Carrd / Edit with MCP
Edit an exported HTML site with an AI agent
Carrd sites often use one route with many section anchors. Give the agent both the route and the target section so it edits the intended content. If a section ID changes, inspect every link pointing to it. New static pages and captured sections are different navigation structures.
Read the guide →Duda / Edit with MCP
Edit an exported HTML site with an AI agent
Duda responsive widgets can have device-specific content and behavior. Before an MCP edit, compare the intended section at two widths and identify the relevant captured text or key. Changing a captured widget does not modify Duda's account, responsive editor settings or appointment backend.
Read the guide →Elementor / Edit with MCP
Edit an exported HTML site with an AI agent
Treat an Elementor capture as HTML, not an editable WordPress theme or Elementor project. Ask the agent to inspect captured markup and plugin-powered sections before changing them. A footer draft edit does not update a WordPress template, and PHP plugin hooks will not appear merely because the visible layout was captured.
Read the guide →Squarespace / Edit with MCP
Edit an exported HTML site with an AI agent
A Squarespace gallery or article capture is editable page output, not its template editor. For agent tasks, specify whether you are changing gallery captions, navigation or article content. Keep external scheduling and commerce links intact unless changing them is part of the approved task.
Read the guide →Strikingly / Edit with MCP
Edit an exported HTML site with an AI agent
For Strikingly, inspect the captured section and anchor target before changing page copy. Additional public pages and one-page sections need different navigation edits. Membership or store widgets can remain externally hosted; updating surrounding HTML does not alter their access rules or order data.
Read the guide →Tilda / Edit with MCP
Edit an exported HTML site with an AI agent
Tilda Zero Block positioning and animation can use coordinated styles and scripts. Ask the agent to inspect the intended section before a localized edit and keep related elements together. The resulting HTML remains a code project, not a Tilda project that can be imported back into its editor.
Read the guide →Weebly / Edit with MCP
Edit an exported HTML site with an AI agent
Weebly .html filenames are part of the site's link structure. When an agent adds a page or updates a menu, review the actual exported path and its link together. A saved HTML change does not update Square inventory or the original Weebly editor's page records.
Read the guide →Wix / Edit with MCP
Edit an exported HTML site with an AI agent
A Wix capture may omit script-built sections. Before an agent edits the output, compare the requested content with the source and mark missing sections explicitly. Editing the available HTML cannot recover Wix CMS data or account logic; a rebuild may be necessary for the intended change.
Read the guide →Reconnect forms
Audit form actions, connect your own submission service and verify delivery, validation and error feedback after moving hosts.
Framer / Reconnect forms
Make forms work after an HTML export
Check Framer contact forms and their confirmation behavior after the HTML converter removes runtime code. A form can still look correct while its submit handler no longer exists. Reconnect delivery to a service you own and test from the deployed domain, including the success state and a deliberately rejected submission.
Read the guide →Webflow / Reconnect forms
Make forms work after an HTML export
Inspect Webflow's generated form wrappers, endpoint and success/error elements together. The copied markup is not Webflow's form inbox, and its handler may depend on original scripts. Test your replacement from the new origin and preserve field names only when they match the receiving service's documented format.
Read the guide →Gamma / Reconnect forms
Make forms work after an HTML export
A Gamma card may embed a third-party contact or signup tool rather than a local form. Identify whether the input lives inside an iframe before editing the surrounding HTML. Configure delivery and allowed origins in that provider, then test the embedded tool on the exported page as well as its standalone URL.
Read the guide →systeme.io / Reconnect forms
Make forms work after an HTML export
An opt-in form is part of a systeme.io automation flow. Test whether the contact reaches the intended list and whether the agreed follow-up runs, not only whether a thank-you page opens. Keep checkout and member authentication with suitable services; never reconstruct those controls from public HTML alone.
Read the guide →Carrd / Reconnect forms
Make forms work after an HTML export
Audit Carrd contact forms and embedded booking tools independently. Some inputs submit directly to an external provider; others rely on page scripts. Keep or replace that service intentionally, test the deployed origin, and confirm the inbox receives your synthetic submission rather than relying on the on-page success message.
Read the guide →Duda / Reconnect forms
Make forms work after an HTML export
Duda contact and appointment widgets need a receiving service even when their fields are visible in the export. Record whether each widget submits to Duda or another provider. Test a synthetic contact and booking on the preview, including validation and confirmation, before replacing the original site's customer flow.
Read the guide →Elementor / Reconnect forms
Make forms work after an HTML export
Elementor and WordPress form plugins often call WordPress endpoints and may use request tokens tied to the original site. Inspect those calls before deployment. Retain a supported backend or replace it deliberately; copied PHP plugin settings, logins and form delivery do not run on static hosting.
Read the guide →Squarespace / Reconnect forms
Make forms work after an HTML export
Squarespace forms, scheduling and commerce have different receiving systems. Inventory them separately so a working booking link is not mistaken for a migrated form inbox. Verify a test submission and a booking through the service you intend to keep, using the new origin and its final success destination.
Read the guide →Strikingly / Reconnect forms
Make forms work after an HTML export
Audit Strikingly contact, store and member widgets independently. A static contact layout is not a submissions inbox, and a login-looking section does not enforce permissions. Test the intended receiving service and preserve working store destinations until a complete replacement flow has been demonstrated.
Read the guide →Tilda / Reconnect forms
Make forms work after an HTML export
Tilda forms can connect to CRM or notification integrations that do not transfer with their visual fields. Record field names, original receiver and success behavior before replacing them. Submit a synthetic lead on the deployed domain and confirm that the chosen CRM or inbox receives it exactly once.
Read the guide →Weebly / Reconnect forms
Make forms work after an HTML export
Weebly contact delivery and Square commerce should be tested as separate flows. A captured product page cannot process inventory or orders by itself. Keep purchase actions with a supported commerce service, and confirm both form receipt and the actual checkout destination from the exported preview.
Read the guide →Wix / Reconnect forms
Make forms work after an HTML export
Wix Forms, bookings and store actions rely on hosted systems. A copied input or booking button is not a migrated backend. Inspect every action and choose retained or replacement services; if key controls are missing from the capture, rebuild them before claiming the form or purchase journey is usable.
Read the guide →CMS & content
Separate captured article pages from the original CMS, inventory content and choose a tested publishing workflow for future updates.
Framer / CMS & content
Maintain CMS content after exporting a website
Inventory Framer collection item paths before conversion. Captured articles can survive as static files without the Framer CMS editor or its future publishing pipeline. In FNJ, inspect whether an extracted collection actually has a publishing template before adding items; storage fields and a rendered item URL are different capabilities.
Read the guide →Webflow / CMS & content
Maintain CMS content after exporting a website
A captured Webflow collection item is an HTML page, not a transferred collection record with all field definitions and filters. Compare public CMS paths with your inventory and rebuild the future publishing workflow explicitly. Do not promise Webflow designer editing or automatic sync from later collection updates.
Read the guide →Gamma / CMS & content
Maintain CMS content after exporting a website
Gamma cards and linked public pages should be inventoried as captured content rather than assumed to be a CMS collection. If you need repeatable articles afterward, define a new content schema and page template. Keep presentation/deck data separate; FNJ does not import Gamma workspace records into that schema.
Read the guide →systeme.io / CMS & content
Maintain CMS content after exporting a website
Inventory public sales, content and confirmation steps separately from member-only course material. Public-page capture does not transfer contacts, course entitlements or email sequences. A new FNJ collection can organize public content, but it must not be treated as a replacement for member authentication or purchase records.
Read the guide →Carrd / CMS & content
Maintain CMS content after exporting a website
A one-page Carrd export may need only manually maintained cards or sections, rather than a full CMS. If you add a collection, choose how its records reach visible content: a listing section or separate cloned pages. Do not mistake section anchors for collection item routes.
Read the guide →Duda / CMS & content
Maintain CMS content after exporting a website
Separate public Duda content pages from dynamic data and account-managed widgets. Use the capture report to identify which pages exist, then plan new content in a supported static or CMS workflow. A blocked source route cannot be replaced by inventing a collection record with the same title.
Read the guide →Elementor / CMS & content
Maintain CMS content after exporting a website
Keep a separate WordPress database backup when records, users and plugin configuration matter. Captured posts are public pages, not a transferable WordPress admin. Decide whether future posts use static files or another CMS, and preserve article routes while verifying one new publishing example.
Read the guide →Squarespace / CMS & content
Maintain CMS content after exporting a website
List public blog articles and gallery pages; protected member content is not part of a public HTML export. Future Squarespace posts will not sync automatically. Choose how article listings and detail pages are maintained in the new workflow, and confirm that a draft item actually gets a reachable published route.
Read the guide →Strikingly / CMS & content
Maintain CMS content after exporting a website
Distinguish Strikingly sections from real public content pages and protected member material. Public HTML cannot transfer membership records or access rules. If you introduce a public content collection, verify its rendering and URLs separately from any service responsible for authenticating members.
Read the guide →Tilda / CMS & content
Maintain CMS content after exporting a website
Inventory public Tilda content and unlinked campaign pages separately. Static page capture does not recreate an editor-managed content collection or CRM. When adding a new FNJ publishing workflow, reuse a suitable page layout, define structured fields deliberately and test the rendered item route before publishing a larger set.
Read the guide →Weebly / CMS & content
Maintain CMS content after exporting a website
Inventory public Weebly blog or content pages with their exact paths. Keep any structured records through an authorized backup from the original service; the HTML bundle is not a Square or Weebly database export. A new collection needs a verified template or a separately maintained page workflow.
Read the guide →Wix / CMS & content
Maintain CMS content after exporting a website
Wix CMS, member records and booking data are not exported by capturing a public page. Inventory visible content and obtain authorized structured data separately when needed. Rebuild missing dynamic sections or choose a new CMS workflow; verify a real item page instead of treating a successful fetch as a collection migration.
Read the guide →URLs & SEO
Map old and new routes, check canonical tags and metadata, test redirects and review indexability on the final domain.
Framer / URLs & SEO
Preserve URLs and SEO when moving an exported site
For Framer, compare CMS slugs and collection detail paths as well as the homepage. The deployed domain should own its canonical URLs. Keep equivalent article routes or map changed ones explicitly, and review redirects through the final hostname before removing the original hosted site.
Read the guide →Webflow / URLs & SEO
Preserve URLs and SEO when moving an exported site
Review Webflow collection folders and item slugs, not just static page names. Some old links may target the webflow.io address while others use a custom domain. Normalize your internal links and canonical URLs for the chosen final hostname and test each changed collection path through its relevant redirect.
Read the guide →Gamma / URLs & SEO
Preserve URLs and SEO when moving an exported site
Separate Gamma card anchors from actual page URLs in your migration map. An in-page section ID is not a new crawlable article route. Preserve useful anchor targets when editing cards, and give independently published pages their own titles and canonical URLs on the final host.
Read the guide →systeme.io / URLs & SEO
Preserve URLs and SEO when moving an exported site
Map funnel step addresses and confirmation paths before moving hosts. Preserve campaign query strings where your services need them, and check that a redirect does not send a purchaser to a generic marketing page. Canonicalize public content pages thoughtfully; private transaction and member flows have different requirements.
Read the guide →Carrd / URLs & SEO
Preserve URLs and SEO when moving an exported site
For Carrd, preserve section IDs used by existing links and ads. An anchor such as #contact does not create another HTML page or sitemap entry. If you introduce separate pages, give them real routes and update navigation intentionally while retaining useful landing-page anchors.
Read the guide →Duda / URLs & SEO
Preserve URLs and SEO when moving an exported site
Use the published Duda custom-domain paths as your route baseline. A capture block or omitted page should be fixed or explicitly replaced before DNS changes. Redirecting a missing business page to the homepage hides the gap from a casual menu test but does not preserve its content.
Read the guide →Elementor / URLs & SEO
Preserve URLs and SEO when moving an exported site
Audit WordPress permalinks, category links and article pagination alongside Elementor landing pages. If you remove archive or search functionality, provide an honest navigation replacement instead of publishing empty copied shells. Map changed article paths specifically and review canonical tags inherited from the old WordPress origin.
Read the guide →Squarespace / URLs & SEO
Preserve URLs and SEO when moving an exported site
Check Squarespace article and gallery slugs plus any scheduling or store destinations that remain external. Preserve public article paths where possible and separate deliberate external service links from stale internal links. A new domain canonical should identify the corresponding article, not collapse the whole blog to one URL.
Read the guide →Strikingly / URLs & SEO
Preserve URLs and SEO when moving an exported site
Keep section anchors used in Strikingly navigation and inventory any additional public paths. Member and store links may intentionally stay external. Update only the links that should become local, and do not create sitemap entries for page sections that have no independent URL path.
Read the guide →Tilda / URLs & SEO
Preserve URLs and SEO when moving an exported site
Tilda campaign pages may be absent from main navigation but still receive traffic through old URLs. Include those authorized public paths in the migration inventory. Preserve useful section anchors and map any renamed landing pages explicitly, keeping tracking and form destinations distinct from canonical content URLs.
Read the guide →Weebly / URLs & SEO
Preserve URLs and SEO when moving an exported site
Record legacy .html paths and test their behavior on the chosen host. Cloudflare Pages may normalize HTML files to extensionless URLs, so inspect response headers and final canonicals rather than assuming the visible filename is the public URL. Use the actual served path consistently in links and the sitemap.
Read the guide →Wix / URLs & SEO
Preserve URLs and SEO when moving an exported site
Wix pages that depend on scripts must contain usable content in the replacement, not only matching URLs. Inventory item and category paths before changing hosts. If the capture misses the main content, repairing canonical tags alone cannot make it an equivalent page; rebuild or retain the original until it is usable.
Read the guide →Mobile layout
Compare narrow and wide previews, fix overflow and navigation, and verify touch, keyboard and reduced-motion behavior.
Framer / Mobile layout
Repair responsive layouts in exported HTML
Framer HTML output removes the Framer runtime. Compare sticky elements, mobile navigation and entrance motion with the source at the same viewport widths. If an interaction was runtime-driven, CSS alone may not restore it; identify the missing behavior and test a replacement before launch.
Read the guide →Webflow / Mobile layout
Repair responsive layouts in exported HTML
Check Webflow navbars, interaction triggers and collection grids at narrow widths. A retained interaction script may govern open/closed states or initial visibility; deleting it without a replacement can hide content. Test the actual mobile toggle and keyboard focus rather than judging the closed menu's appearance.
Read the guide →Gamma / Mobile layout
Repair responsive layouts in exported HTML
Compare Gamma card order, card spacing and embedded controls on phone and desktop. A presentation-style layout can look correct at one width while videos, documents or tall cards overflow elsewhere. Verify controls inside each embed and avoid hiding overflow that prevents visitors from accessing content.
Read the guide →systeme.io / Mobile layout
Repair responsive layouts in exported HTML
Test opt-in fields, sales CTAs and confirmation content at phone widths. A tall sticky CTA can cover form controls, especially when the keyboard opens. Follow the full funnel in the preview and confirm that responsive repairs do not change the action URL or remove success/error feedback.
Read the guide →Carrd / Mobile layout
Repair responsive layouts in exported HTML
Test section anchor scrolling, embedded widgets and long headings on a narrow Carrd page. Sticky navigation can obscure the target section after a tap. Adjust the layout at the affected breakpoint and check that the same section remains readable at larger widths without forcing a fixed height.
Read the guide →Duda / Mobile layout
Repair responsive layouts in exported HTML
Compare Duda's device-specific sections, image crops and navigation at matched phone and desktop widths. Check whether a widget displays different content on each device. Preserve the intended information in the export rather than hiding the desktop section without providing the corresponding mobile content.
Read the guide →Elementor / Mobile layout
Repair responsive layouts in exported HTML
Test Elementor breakpoints, popup triggers and plugin widgets in the export. Some controls depend on WordPress/plugin scripts despite having complete styling. Confirm the mobile navigation's focus and open state, and review a post page after any shared selector change to avoid fixing one template while breaking another.
Read the guide →Squarespace / Mobile layout
Repair responsive layouts in exported HTML
Compare Squarespace gallery controls, image crops and mobile navigation after capture. Swipe and lightbox behavior may depend on scripts. Review portrait and landscape media on a narrow viewport and keep captions readable; a fixed gallery height can conceal longer content after a font change.
Read the guide →Strikingly / Mobile layout
Repair responsive layouts in exported HTML
Check Strikingly section spacing, menu toggles and store widgets at narrow widths. Follow each anchor with a sticky header enabled to see whether its heading remains visible. Test external membership actions too; matching their button layout does not establish that sign-in works.
Read the guide →Tilda / Mobile layout
Repair responsive layouts in exported HTML
Review Zero Block alignment, font sizes and motion at each intended breakpoint. Fixed positioning can shift dramatically after font substitution or a longer heading. Preserve readable content before recreating decorative motion, and check both reduced-motion behavior and the ordinary animated preview.
Read the guide →Weebly / Mobile layout
Repair responsive layouts in exported HTML
Test Weebly navigation, content columns and Square widgets on phone widths. Compare direct .html route loads as well as navigation from the homepage so routing errors are not mistaken for mobile layout failures. Confirm responsive repairs leave purchase and contact actions usable.
Read the guide →Wix / Mobile layout
Repair responsive layouts in exported HTML
Check Wix mobile layouts, galleries and menus against the actual published page. Script-built controls or content may be absent rather than merely misaligned. Fix or rebuild missing sections before fine-tuning their CSS, and test the exported result at both phone and desktop widths.
Read the guide →Images & fonts
Find failed asset requests, correct relative paths, inspect external dependencies and preserve typography on the new host.
Framer / Images & fonts
Fix images, fonts and assets after an HTML export
Framer output can contain captured image variants and local fonts alongside remaining dependencies. Check which file a responsive srcset actually requests and whether the required font weight loads. Compare the HTML mode's asset references separately from the original Next.js project's runtime modules; they are not identical bundles.
Read the guide →Webflow / Images & fonts
Fix images, fonts and assets after an HTML export
Webflow galleries may reference responsive image variants and external interaction scripts. Inspect srcset and CSS background URLs as well as image tags. Keep a record of which scripts remain remote and test their behavior from the new host before assuming the project no longer depends on Webflow services.
Read the guide →Gamma / Images & fonts
Fix images, fonts and assets after an HTML export
Gamma video and document embeds can stay external even when nearby images are captured locally. Inventory each player and document URL alongside ordinary assets. Replacing an embed with a file requires its own authorized source and controls; uploading the surrounding HTML does not make a hosted player independent.
Read the guide →systeme.io / Images & fonts
Fix images, fonts and assets after an HTML export
Funnel assets can include tracking scripts, embedded checkout and remote course media. Separate design assets from scripts handling business actions before removing dependencies. Keep credentials and contact data out of the export repository, and verify payment destinations using the service's appropriate test process.
Read the guide →Carrd / Images & fonts
Fix images, fonts and assets after an HTML export
Carrd can combine local-looking images with external embeds and CSS backgrounds. Test the whole landing page after lazy-loaded assets appear. Preserve background positioning and compare font wrapping when moving files, and document embedded booking or form services rather than treating them as ordinary downloadable assets.
Read the guide →Duda / Images & fonts
Fix images, fonts and assets after an HTML export
Duda widgets can fetch media and behavior from external endpoints. Check those requests from the deployed preview and record blocked or missing assets. Do not assume a font mismatch is caused by CSS until you verify that the actual font response and required weight are available.
Read the guide →Elementor / Images & fonts
Fix images, fonts and assets after an HTML export
Elementor page styles can reference WordPress upload folders, plugin CSS and externally served fonts. Inspect CSS background URLs and font requests on nested article routes. Keep only needed public dependencies, and maintain a separate WordPress backup; copying uploads alone does not preserve plugin configuration.
Read the guide →Squarespace / Images & fonts
Fix images, fonts and assets after an HTML export
Squarespace image blocks can request remote image variants while galleries depend on controls or scripts. Test responsive images and lightboxes from the new host. Inventory scheduling and store embeds as services, and retain their intended URLs until a working replacement is verified.
Read the guide →Strikingly / Images & fonts
Fix images, fonts and assets after an HTML export
Strikingly widget media and store assets may continue loading from hosted services. Inspect request failures and responsive image sizing separately. Keep widget dependencies documented, and do not mix member or order records with publicly downloadable asset files during handoff to a repository.
Read the guide →Tilda / Images & fonts
Fix images, fonts and assets after an HTML export
Tilda layouts can combine CSS-positioned media, web fonts and scripts controlling motion. Verify font responses before correcting alignment, then inspect images and backgrounds at the same viewport as the source. Removing a remote script requires a behavior review, not just a replacement file name.
Read the guide →Weebly / Images & fonts
Fix images, fonts and assets after an HTML export
Check Weebly assets from both the root page and legacy .html routes. Relative references can behave differently after a host normalizes a path. Preserve images and fonts with the exported pages, and catalog Square scripts as commerce dependencies rather than assuming they are local design assets.
Read the guide →Wix / Images & fonts
Fix images, fonts and assets after an HTML export
Wix media can load through platform endpoints and responsive transformations. Inspect the actual captured files and requested variants before renaming URLs. A remote script may also create the content referencing an image; absent markup and a failed asset request require different repair plans.
Read the guide →Export troubleshooting
Separate URL access errors, capture limits, missing content and deployment problems using a small reproducible conversion.
Framer / Export troubleshooting
Diagnose a failed or incomplete HTML export
For a large Framer site, record whether the last stage was image optimization, runtime processing or page discovery. Try the exact failing URL in This page scope, then compare a full-site attempt against required CMS paths. A smaller result helps diagnosis but does not replace verification of the customer's original full-site input.
Read the guide →Webflow / Export troubleshooting
Diagnose a failed or incomplete HTML export
Use a public Webflow custom domain or published webflow.io URL and test one CMS item in addition to a landing page. If the homepage succeeds but articles are absent, compare discovery against the collection URL inventory. That is a missing-route problem, not necessarily an inaccessible site.
Read the guide →Gamma / Export troubleshooting
Diagnose a failed or incomplete HTML export
Use the published gamma.site or custom-domain website URL, not a private workspace or presentation editing link. Compare captured headings and card content with the signed-out public page. If controls rely on Gamma scripts, record that dependency separately from whether the basic page request succeeded.
Read the guide →systeme.io / Export troubleshooting
Diagnose a failed or incomplete HTML export
Start with a public sales or opt-in URL rather than a dashboard, protected course or checkout session. Record which funnel step fails and whether it is publicly accessible. A complete public-page capture still does not prove that email automation, membership or payment processing migrated.
Read the guide →Carrd / Export troubleshooting
Diagnose a failed or incomplete HTML export
Begin with page scope for a public Carrd landing page and compare every section anchor. Site scope is only useful when additional public pages need discovery. If content opens only through script-driven section navigation, review that interaction separately from the initial downloaded markup.
Read the guide →Duda / Export troubleshooting
Diagnose a failed or incomplete HTML export
Some Duda hosts block automated capture. Open the published domain signed out and try one page; record any access error. FNJ cannot bypass access controls. Resolve the block with the site owner or source host before retrying a full crawl or describing the missing output as deployable.
Read the guide →Elementor / Export troubleshooting
Diagnose a failed or incomplete HTML export
Use a published WordPress URL and inspect whether missing content comes from an Elementor section or another plugin template. Admin and password-protected posts are outside a public capture. Reproduce on one representative landing page and one post before interpreting a full-site crawl failure.
Read the guide →Squarespace / Export troubleshooting
Diagnose a failed or incomplete HTML export
Use a live Squarespace address and test an article or gallery as well as the homepage. A members-only page is not a failed public article capture. Compare captured paths with the public inventory, then distinguish an undiscovered route from a downloaded page whose gallery controls still need repair.
Read the guide →Strikingly / Export troubleshooting
Diagnose a failed or incomplete HTML export
Start with page scope for a section-based Strikingly site, then inventory additional linked pages before a broader crawl. Protected member areas cannot be captured as public content. If a section requires interaction to appear, record whether the content or its controlling behavior is missing.
Read the guide →Tilda / Export troubleshooting
Diagnose a failed or incomplete HTML export
Use a published Tilda address rather than a project editing link, and test a representative Zero Block page first. Campaign pages that are not linked may require explicit inventory. Report whether the failure concerns capture access, page discovery or missing motion in an otherwise downloaded page.
Read the guide →Weebly / Export troubleshooting
Diagnose a failed or incomplete HTML export
For Weebly, record the exact failing .html path and distinguish export success from host routing behavior. FNJ writes captured .html routes as files, while the destination host can normalize their public URLs. Test the local preview, then the uploaded route and redirect headers separately.
Read the guide →Wix / Export troubleshooting
Diagnose a failed or incomplete HTML export
Start with one public Wix page and compare its visible text and controls carefully. A 200 response can contain a script shell without the necessary content. If core sections remain missing, record the gap and plan a rebuild; do not represent a full crawl as a complete Wix application migration.
Read the guide →