iPage

Webflow hosts sites but isn't a domain registrar and doesn't host email, so a domain and mailboxes bought from iPage stay under iPage's control. Webflow can't accept a domain transfer. Nothing in Site settings edits the zone file at iPage either, and iPage's DNS help documents no API for record changes.

Three DNS records entered at iPage put the site on Webflow hosting while registration, DNS and email stay put. SSL certificates issue automatically once those records resolve, and the Webflow CMS, forms and Ecommerce keep working because the site never leaves Webflow. Teams that want the reverse can export the site's code and upload the static files to iPage hosting.

This guide fits small business owners whose domain and mailboxes live at iPage and who want a Webflow site at that address. Freelancers and agencies building on client-owned iPage domains use the same records to go live without touching the client's email. Teams moving a WordPress site off iPage shared hosting follow the same DNS cutover after importing content into the CMS.

How to integrate iPage with Webflow

What is iPage? iPage is a web hosting and domain registration brand that has operated since 1998. Its user agreement names Newfold Digital, Inc. as the contracting company and says iPage customers, apart from resellers and their customers, migrate to Network Solutions on or about February 20, 2026. iPage's login page now reads "iPage is now part of Network Solutions" and tells existing customers to keep using their iPage login details. The iPage help center still documents hosting, domains, DNS, email mailboxes and FTP under the iPage name.

Most teams pair the two because the domain already exists at iPage and the new site is built in Webflow. Keeping the domain where it is avoids a registrar transfer and an email migration. The less common case runs in reverse, where a team exports a finished Webflow site and hosts the static files on an iPage shared plan.

The iPage-Webflow integration supports three approaches:

• Manual DNS connection points an iPage-registered domain at Webflow hosting with A, CNAME and TXT records, with no code involved.
• Code export with FTP upload lets you host a static copy of a Webflow site on iPage shared hosting.
• The Webflow Data API and webhooks give you full control over publishing, form routing and content migration, but require server-side development and a manual iPage side.

The first method covers most production sites. The export path trades Webflow hosting for iPage hosting, and the API path adds automation on top of either.

Point your iPage domain at Webflow with DNS records

Adding three records in the iPage Domains Dashboard connects your domain to a Webflow-hosted site. DNS pointing is the standard route for production sites because CMS, forms and Ecommerce stay intact. You need a paid Site plan for every site you connect to a custom domain, plus login access to the iPage account that holds the domain. Quick connect through Entri also sits in Site settings: start it and check whether iPage appears in the provider search, or follow the manual path below. Keep iPage's default nameservers, ns1.ipage.com and ns2.ipage.com, in place; the zone file at iPage only applies while they do. If iPage's login now sends you to Network Solutions, make the same record changes in that account; our Network Solutions guide covers its dashboard.

Add the A, CNAME and TXT records in the iPage Domains Dashboard

Webflow generates three records when you add a domain manually, and iPage accepts all three through its DNS Records tab. Copy the values Site settings displays rather than typing them from memory.

To connect the domain:

1. In Webflow, go to Site settings > Publishing > Production, click Add a custom domain, choose Manually add domain, enter your domain and click Add domain. This connects both the root and www.
2. Note the records Site settings shows, which match Webflow's manual connection guide: an A record for @ pointing to 198.202.211.1, a CNAME for www pointing to cdn.webflow.com, and a TXT record on _webflow holding the site-specific one-time-verification= value.
3. Log in to the iPage Domains Dashboard and select the domain. Click Manage in Card view, or the domain name or gear icon in List view. Open DNS & Nameservers in the left sidebar, then the DNS Records tab.
4. Open the three-dot menu on the existing @ A record, replace its value with 198.202.211.1 and click Update DNS. Delete any other @ A record; extra root A records conflict.
5. If www currently exists as an A record, delete it so one record serves that subdomain. Click the blue + button, choose CNAME, enter www as the host name and cdn.webflow.com as the content, then click Add DNS.
6. Click + again, choose TXT, enter _webflow as the host, paste the one-time-verification= value and click Add DNS. iPage lists TXT records at the bottom of the tab if you need to edit one later.
7. Back in Webflow, click Check status, then Verify domain. Once the "Custom domain verified" confirmation appears, click Publish and choose Publish to selected domains.

iPage's DNS records article says changes "may take 24-48 hours" to take effect, while Webflow's manual connection guide lists up to 48 hours and typically a few hours. Webflow's live-site migration article recommends lowering the TTL to the lowest value available, typically 30 seconds, at least one full TTL period before the cutover and restoring it afterward. iPage's DNS glossary, by contrast, says to leave the TTL field at its default, so treat the lower TTL as optional at iPage. If iPage rejects @, enter the full domain; if the CNAME fails, try cdn.webflow.com. with a trailing dot. With more than one domain connected, set the default under Site settings > Publishing > Production with Make default and publish again. SSL issues automatically once DNS resolves to Webflow and renews as long as the records stay in place. If you publish CAA records at iPage, add 0 issue "letsencrypt.org" and 0 issue "pki.goog; cansignhttpexchanges=yes" per the CAA article, or issuance fails.

Keep iPage email working through your MX records

Webflow hosting does not include email, so your MX records keep pointing wherever your mail lives, per the hosting overview. With iPage nameservers in place, the default MX record is your domain name resolving to a local IP, which routes mail to the iPage mailboxes. iPage's MX format examples point at an mx. host on your domain, such as mx.yourdomain.com, rather than at the root.

To keep email on iPage during the cutover:

1. Before changing anything, run a DIG or WHOIS lookup to confirm where the domain's MX record currently resolves, as iPage's MX article advises.
2. In the DNS Records tab, leave both MX records untouched. iPage's instruction is to "Make sure that your MX records are pointing to your hosting account."
3. After the site goes live, send a test message to an iPage mailbox and open iPage Webmail at webmail.yourdomain.com, or through Email Management > Standard > Launch Email, to confirm delivery.
4. If a mail client loses its connection, re-enter IMAP imap.ipage.com (ports 143/993) and SMTP smtp.ipage.com (ports 587/465) from the email client setup article.

iPage's email troubleshooting article says Webmail fails if your MX records, or the A records behind them, don't point to iPage. Those are the records for the mx. host, not the root @ A record you repoint at Webflow, so leave them alone; the test in step 3 is the real confirmation. If the nameservers already point somewhere other than iPage, MX edits happen at that provider instead.

Host a Webflow code export on iPage with FTP or File Manager

Exporting a site's code and uploading it to iPage shared hosting produces a static copy that runs without a Webflow Site plan. Code export requires a paid Core, Growth, Freelancer or Agency Workspace plan; Site plans don't include it. The export is a ZIP with CSS, JS and images folders plus an .html file for every page. This route trades dynamic features for static hosting, which suits brochure sites, portfolios and landing pages that rarely change. Every edit afterward means a fresh export and re-upload.

To publish an export on iPage:

1. In Webflow, open the Main menu, click Code export (or press Shift + E), click Prepare ZIP and download the file.
2. Connect to iPage with an FTP client such as FileZilla using host ftp.yourdomainname.com and port 21, or port 2222 with the "SFTP - SSH File Transfer Protocol" option.
3. Upload the unzipped export, including the CSS, JS and images folders, into the directory iPage labels Home or Public for your domain. Keep the export's index.html in that folder so the home page loads.
4. For a handful of files, use Hosting Summary > File Manager, select the folder and click Upload. Large files time out, so zip them first and extract with Hosting Summary > Hosting Tools > Launch beside Archive Gateway.
5. Turn on HTTPS at Domains Dashboard > Manage > Summary > Domain Settings by toggling Let's Encrypt Free SSL. The domain's A record must point at the iPage hosting IP for issuance.

The static copy keeps the following:

• Clean output: Full HTML, CSS and JS ships with no Webflow attribution and no ongoing Webflow plan.
• Interactive components: Navbars, sliders, tabs and interactions keep working as long as the JS folder stays intact.
• Minified HTML: Pressing Command + O on Mac or Control + O on Windows in the export window adds a Minify HTML checkbox before you click Prepare ZIP.
• Scoped FTP access: iPage lets you add secondary FTP users limited to specific folders under Hosting > FTP Management > Add FTP Account.

The export leaves out the CMS, Ecommerce, password protection, form processing, reCAPTCHA, site search, code components and non-primary locales. Collection List elements render their empty state, though CMS and Ecommerce Collections can be exported as CSV backups. The customer support policy excludes exported code running outside Webflow, so iPage support handles server questions from that point.

Collect form submissions on an exported site with a custom action

Webflow won't process submissions from an exported site, so each form needs a third-party endpoint before you export. The custom action setting swaps Webflow's processor for the provider's URL and stops Webflow notifications for that form.

To route a form:

1. Copy the action URL from your form provider.
2. Select the form in Webflow, open its settings, choose Custom Action under Send to, and paste the URL into Action.
3. Match the method (POST or GET) the provider expects, then run the code export.
4. Upload the export to iPage and submit a test entry.

iPage documents its own Form Email processor at https://www1.ipage.com/scripts/formemail.html for sites on its hosting; it "takes a website form and sends its contents to a specified email address" and then redirects the browser. Test it against an exported form before building a site around it.

Build with the Webflow Data API and webhooks

The Webflow Data API covers the Webflow half of any automated workflow; the iPage half stays manual, because iPage's help documents no customer-facing API or webhook for DNS, files or mail. Its TXT-record article even routes "TXT updates using API records" to customer service. That leaves three workflows worth building. Each needs a server you control to hold tokens and receive webhooks.

• Webflow's Data API handles sites, CMS collections and form submissions over REST at https://api.webflow.com/v2.
• Webflow webhooks trigger real-time events such as form_submission and site_publish.
• iPage FTP and SFTP and phpMyAdmin are iPage's documented ways to move files and data off iPage.

No webhook trigger exists for DNS changes, and the Data API has no endpoint for editing DNS records, so the record edits at iPage stay a manual step in every workflow below.

Publish to the iPage domain after a DNS change

Once the records at iPage resolve, a publish call pushes the site to the verified custom domain without opening Webflow. This suits agencies that cut over many client domains and want a scripted go-live.

To publish from a script:

1. Call GET /v2/sites with the sites:read scope to find the site ID.
2. Call GET /v2/sites/{site_id}/custom_domains to list the domain IDs connected to the site.
3. Send POST /v2/sites/{site_id}/publish with the sites:write scope. The body needs at least one of customDomains (an array of domain IDs) or publishToWebflowSubdomain (boolean, default false). Pass pageId to publish a single page.
4. Register a site_publish webhook with POST /v2/sites/{site_id}/webhooks to confirm the publish; the payload carries siteId, publishedOn, domains and publishedBy.displayName.

Verify the domain in Site settings before the first call. Publishing to a domain that still points at the legacy DNS values has been blocked since January 13, 2026.

Forward Webflow form submissions to iPage email

A form_submission webhook plus a small relay delivers Webflow form data to an iPage mailbox over SMTP. Hosted submissions and native notifications keep working alongside it, so the relay adds a copy in the iPage inbox rather than replacing anything.

To build the relay:

1. Create the webhook with POST /v2/sites/{site_id}/webhooks, setting triggerType to form_submission and, optionally, filter.name to limit it to one form. Creation needs a bearer token from a Data Client App and the sites:write scope.
2. Receive the POST on your endpoint. Webflow sends Content-Type: application/json with x-webflow-timestamp and x-webflow-signature headers; the body carries triggerType and a payload with name, siteId, data, submittedAt, id and formId, as the form submission event reference lists.
3. Verify the signature by computing a SHA-256 HMAC, keyed with your site token secret or OAuth app client secret, over timestamp + ":" + JSON.stringify(request_body). Reject timestamps more than 5 minutes old.
4. Send the data fields to the iPage mailbox through smtp.ipage.com on port 587 or 465, authenticating with the mailbox credentials.

Webflow retries a failed delivery 3 times, 10 minutes apart, so the endpoint should return fast and queue the SMTP send. If polling fits better than a webhook, GET /v2/sites/{site_id}/form_submissions returns submissions across the site with the forms:read scope.

Migrate iPage-hosted content into the Webflow CMS

Content from a WordPress or custom site on iPage reaches the CMS through a database export and the Collections, Items and Assets endpoints. The extraction step is a phpMyAdmin download plus SFTP for media, since no iPage API exists. For a typical WordPress blog, the CSV import is faster than coding against the API; the API pays off when you need to transform fields, upload thousands of images or rerun the import.

To migrate via the API:

1. On iPage, go to Hosting Dashboard > MySQL Management > Manage > phpMyAdmin > Export > Quick > SQL > Go to download the database. Pull the uploads folder over SFTP on port 2222.
2. Call GET /v2/collections/{collection_id} to read the target schema; field types include PlainText, RichText, Image, MultiImage, Reference and MultiReference.
3. For each image, send POST /v2/sites/{site_id}/assets with fileName (under 100 characters, with extension) and an MD5 fileHash. The response returns uploadUrl and uploadDetails for a POST to Amazon S3.
4. Create items with POST /v2/collections/{collection_id}/items, passing a single fieldData object or an items array, each entry with optional cmsLocaleId, isDraft and isArchived. Reference uploaded images by fileId and url.
5. Publish with POST /v2/collections/{collection_id}/items/publish, which sets isDraft to false.

Webflow's reference keeps this endpoint supported but points new integrations to the newer Create Items endpoint, which accepts the same two request shapes. Map every old iPage URL to a 301 redirect before pointing DNS so existing links keep resolving.

What you can build with the iPage Webflow integration

Integrating iPage with Webflow lets you launch a Webflow-hosted site on a domain you already own without transferring the registration, rebuilding email or paying for a second host.

• Business site on an existing iPage domain: A local services company keeps example.com and its mailboxes at iPage and points the root and www at a Webflow marketing site. The SSL certificate issues once the A and CNAME records resolve, and the CMS blog, native forms and Ecommerce checkout all stay live.
• Agency launch on a client-owned domain: A freelancer builds the client's site in Webflow and sends the three DNS values for the client to enter in their Domains Dashboard. The client keeps registration, webmail and billing at iPage, and the agency never needs the client's primary FTP credentials.
• WordPress blog moved off iPage shared hosting: A solo creator exports a blog's posts to CSV, imports them into a CMS Collection with field mapping, maps each old URL to a 301 redirect, then repoints DNS at Webflow with the TTL lowered. Editors publish from the CMS afterward without plugin maintenance.
• Static portfolio on iPage hosting: A photographer exports a five-page portfolio from a Core Workspace, uploads it over SFTP to iPage, toggles Let's Encrypt and routes the contact form to a third-party action URL. No Site plan is needed, and each update is a new export.

If you need more control over publishing timing, submission routing or bulk content loads, the API path above covers those cases.