Site URL
Use the website address you normally visit in the browser. If needed, include the full https:// version.
INSTALLATION GUIDE
A simple step-by-step guide for downloading the plugin, installing it in WordPress, and creating the one-time password used to connect your site.
Follow these steps in order. Most sites only take a few minutes.
Download the WPFlow Connect plugin to your computer so it is ready to upload into WordPress.
Open your WordPress admin area, which is usually your website address followed by /wp-admin/, then sign in with an administrator account.
In WordPress, go to Plugins, choose Add New, then choose Upload Plugin. Select the WPFlow Connect zip file you downloaded.
Click Install Now, wait for WordPress to finish, then click Activate so the plugin is live on your site.
Go to Users, then Profile. Find the Application Passwords section, type WPFlow Connect as the name, click Add New, and copy the password shown. WordPress only shows it once.
Return to WPFlow onboarding and paste your Site URL, Admin username, and the one-time Application Password so WPFlow can pair your site securely.
Simple setup. Secure pairing. No coding required.
WPFlow asks for three details so it can complete the secure connection.
Use the website address you normally visit in the browser. If needed, include the full https:// version.
Use the real WordPress login name for an administrator account, not a nickname or display name.
Paste the password WordPress shows after you click Add New in your profile. Copy it straight away because it is only shown once.
Clear answers to the questions that matter before you get started.
Start by choosing the trial or sign-up path, completing the required confirmations, adding payment authority through Stripe, and connecting your WordPress site.
WPFlow then prepares or validates staging and runs supportability checks. Once the account reaches the ready state, you can start sending normal requests through the workspace.
The trial is designed to let you test WPFlow on a real staged version of your site, not lose trial time while setup is still being prepared.
WPFlow needs confirmation that you are authorised to request and approve work for the site, payment authority, a guided WordPress connection, and permission to prepare or use staging.
Depending on the site, WPFlow may also need details such as the production URL, WordPress admin URL, staging information, key pages or journeys, the main technical contact, theme details, plugin context, hosting constraints, and the person who can approve live releases.
Do not paste passwords, API keys, payment secrets, private keys, or database credentials into chat or ordinary messages. Use the approved secure connection or support route.
You do not necessarily need to have staging ready before you start. WPFlow can create, adopt, or normalise staging where the hosting setup and permissions allow it.
A viable staging path is required for standard work. Staging is where WPFlow prepares and checks changes before your live site is touched, so it is central to the safety of the service.
Supportability checks confirm whether WPFlow can work on your site safely and reliably.
They look at practical factors such as site authority, access, staging readiness, hosting constraints, theme approach, plugin risk, publish mode, key user journeys, rollback readiness, security health, and whether the requested work fits the standard model.
The result should be clear: ready for standard work, needing remediation first, or requiring a custom route.
Onboarding is designed to be low-friction for supported sites. Many sites can move through setup quickly once connection details and permissions are complete.
For the broader operational promise, supported sites can be prepared within the stated onboarding target once payment or trial activation, access, supportability checks, credential verification, and staging readiness are all in place.
The important point is that the trial clock starts when staging is ready, so you can test WPFlow on a prepared environment rather than spending trial time on setup.
If your site is close to being supportable but needs a fix first, WPFlow should make that clear and route it into remediation.
Remediation might involve access, staging, theme setup, plugin risk, security health, deployment, or rollback readiness. Some issues are simple; others need separate scoping or a custom route.
The aim is to get your site into a safe, reliable working state before normal requests begin, rather than onboarding a site that cannot be supported properly.
Often, yes. WPFlow is designed to work with your existing WordPress setup where the site fits the support rules.
During onboarding, WPFlow checks the practical details: access, staging, hosting constraints, theme approach, plugin risk, publish mode, and the type of work you are likely to request. WPFlow is not limited to one theme or one page builder, but the site needs a safe staging and release path before normal work begins.
Usually no. WPFlow is designed to work with your current WordPress setup where the site is supportable, so moving hosting or DNS is not the default requirement.
What WPFlow does need is a safe way to connect to the site, prepare or use staging, review changes, and publish approved work. If hosting, DNS, or staging changes are genuinely needed for your site, they should be surfaced as clear onboarding facts rather than hidden surprises.
The free trial includes 7 days and 5 trial credits. The trial starts when staging is ready, not at raw sign-up.
That is important because you should be able to test WPFlow on a prepared staging environment instead of losing trial time during setup. Payment authority is captured before staging is provisioned, and Stripe handles payment details securely.
Trial credits expire at the end of the original trial period.
No. WPFlow is staging-first, and live release is a separate governed action.
Work is built and reviewed on staging first. Completing a request on staging does not automatically update the live site. Live publishing happens through the Live Release Centre and requires approval from an authorised role.
The Assistant also cannot publish live, approve work, mark staging complete, or bypass the governed workflow.