What you will have afterward
A form whose submissions reach the intended inbox or system from the new website origin. The exported fields are the interface; message delivery, abuse controls and stored submissions belong to the service you connect.
Before you start with Strikingly
Check section-based navigation and any additional public pages separately. Store and membership widgets can be visible in a capture without their hosted data or permissions moving with them.
Strikingly sites often combine section-based navigation with platform widgets. A useful HTML migration checks both: visitors need to reach the right section and complete the actions those widgets offer. Read the migration guide.
What matters for Strikingly
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.
Make forms work after an HTML export
- 01
Inventory each submission flow
Record the form's page, fields, required inputs, submit action and success screen. In the exported preview, inspect the browser Network panel while submitting synthetic data. Note the endpoint and response; a success animation is not evidence that a message was delivered.
- 02
Choose a service you control
Keep a compatible existing endpoint or choose a form provider in your own account. Check allowed origins, field names and any server-side validation. Do not put API secrets in HTML or browser JavaScript. If authentication needs a secret, use your own server-side endpoint rather than exposing it.
- 03
Reconnect the page and feedback
Update the form action or submission script in the code, or use the agent to draft an appropriate section through FNJ. Preserve labels, keyboard operation, required-field messages and success/error states. Match the new service's documented request format; replacing a URL alone may not be sufficient.
- 04
Test delivery from the deployed origin
Send a clearly labeled synthetic submission on the preview and final domain. Verify receipt in the intended service, then test missing required fields and a rejected request. Review rate limiting and abuse protection in that service. Remove test records afterward and retain no real customer data in public code.
Give your agent a clear starting point
Copy this prompt for your connected agent and fill in the project details. Tasks that inspect browser requests, edit downloaded files or configure another service may need your agent's own browser or code tools. FNJ MCP alone does not configure those external services. Keep credentials in the relevant account's setup screen, never in the prompt.
Source: Strikingly. Output: static HTML, not the original builder workspace. Audit forms on my FNJ HTML site [site ID], routes [routes]. Identify existing submission endpoints and dependent scripts. Use [my chosen form service] with its documented public integration. Preserve labels and styling; add accessible success and failure states. Never put secrets in client code or request them in chat. Show proposed edits and a synthetic delivery test plan before publishing. Report any integration that needs tools beyond FNJ MCP. Platform checks: 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.
Use with your own agent. Replace bracketed values.
Verify the result before launch
- A test submission reaches the intended destination.
- Invalid fields and failed requests produce useful feedback.
- The browser bundle contains no server-side credentials.
Use the final hosted preview as well as the saved FNJ draft. Keep a backup of the reviewed files, record what remains external and test the important customer action on the final domain. A draft edit, downloaded ZIP and live site can represent different versions until you export and deploy the intended one.
Common questions
- Does exporting a form also export its inbox or automation?
- No. Public markup does not transfer stored submissions, an email delivery system, CRM contacts or automation rules. Reconnect and test those services separately before moving traffic.
- Can I cancel Strikingly hosting right after exporting?
- First verify the content, assets, routes and business actions on the replacement host. Follow mobile section navigation and test store or membership actions through their actual service endpoints. Keep or replace external dependencies before relying on the new site.
- Where do these HTML changes get deployed?
- Use a compatible static host in your own account. FNJ supports deploying the saved site to your own Cloudflare Pages account, and exporting code to your own GitHub repository. A GitHub push stores code; configure hosting separately and confirm the reviewed version is what visitors receive.