getting started

Connect WordPress

Username + Application Password. Native auth, no plugins.

Quibo connects to WordPress using Application Passwords, a native feature in WordPress 5.6+. No plugin, no OAuth dance, no custom endpoint. You generate a one-purpose password from your admin profile and paste it into Quibo.

What you'll need

  • A WordPress user with the Administrator or Editor role on the site. For the structured data to reach your pages, that user also needs the unfiltered_html capability (see Structured data and unfiltered_html below).
  • Your WordPress username (the login name, not the display name).
  • An Application Password generated for Quibo.
  • The site served over HTTPS and reachable from the public internet.

Generate the Application Password

  1. Sign into your WordPress admin.
  2. Go to Users, then Profile (or Edit Profile from the top-right avatar if you're editing your own user).
  3. Scroll to the Application Passwords section near the bottom.
  4. In New Application Password Name type Quibo and click Add New Application Password.
  5. Copy the 24-character password that appears (format xxxx xxxx xxxx xxxx xxxx xxxx). It's only shown once. You can leave the spaces: WordPress strips them when checking.

Plug it into Quibo

From Sites, then Connect a site pick WordPress and fill in:

  • Site name (e.g. Acme Blog)
  • Site URL, the public address of your WordPress site (e.g. https://example.com)
  • Output language, the language the articles are written in
  • WordPress username
  • Application Password

Click Connect site. Quibo first verifies the credentials against WordPress: if the check fails, nothing is stored and the error is shown in the wizard. When it passes, Quibo encrypts the credentials, starts learning your brand voice and probes the REST API (see below). Test connection on the site page stays available to re-check them later.

Auto-discovery

After connecting, Quibo probes the WordPress REST API to discover:

  • Post fields, from OPTIONS /wp-json/wp/v2/posts. Kept for reference: publishing does not depend on them, Quibo always sends the fields listed under What we publish.
  • Post types, from GET /wp-json/wp/v2/types. Listed for reference only: Quibo always publishes to the standard post type.
  • Editorial users, from GET /wp-json/wp/v2/users?context=edit (up to 100). They power the Default author dropdown so you can pick which user appears as the byline on Quibo-generated posts.

Open Sites, then your site, scroll to Brand profile, pick the Default author and click Save brand profile. Every article Quibo publishes will be attributed to that user. If none is saved, WordPress attributes the post to the user that owns the Application Password.

Discovery runs again once a day, or whenever you click Re-crawl brand on the site page.

What if Application Passwords are disabled?

Some hosts (or security plugins such as iThemes Security) disable Application Passwords by default. Symptoms:

  • Test connection answers Authentication failed. Check user + Application Password.
  • The Application Passwords section doesn't appear in your Profile.

Ask your host or admin to re-enable Application Passwords. Most hosts have a one-line fix in functions.php:

add_filter( 'wp_is_application_passwords_available', '__return_true' );

...or via a small must-use plugin. Once enabled, generate a new password, then open the site page in Quibo, use Update credentials in the Credentials card, and the new values are verified against your CMS before they replace the old ones.

If your site is behind aggressive bot protection (Cloudflare Bot Fight Mode, custom WAF rules), make sure requests to /wp-json/wp/v2/* from external services are allowed.

What we publish

When an article ships to your WordPress, we upload the cover first, then send one POST /wp-json/wp/v2/posts with:

  • Title, slug and excerpt (the meta description). When an article has no meta description the excerpt is left out, so an update never blanks yours.
  • Content rendered as native Gutenberg blocks, with the article's JSON-LD (Article with the AI-generated marking, FAQPage and BreadcrumbList) appended in a Custom HTML block. Quibo sets the Article publish date when the post goes live (the modified date on any later update) and points its image at the cover in your media library.
  • The cover image, uploaded to your media library with its alt text and set as the featured image. Like every cover, it comes without the image service's embedded Content Credentials (C2PA) block and with an XMP marking that identifies the file as AI-generated, as required by the EU AI Act. The pixels are not changed.
  • The SEO title and meta description for your SEO plugin (see below)
  • The chosen Default author (numeric author field)
  • status: publish, so the post goes live immediately

We never delete or modify other posts. We don't touch user accounts. We don't write to site options.

SEO plugins

PluginWhat Quibo writes
Jetpack SEOSEO title (jetpack_seo_html_title) and meta description (advanced_seo_description)
Yoast SEO 27.7 or laterSEO title (_yoast_wpseo_title) and meta description (_yoast_wpseo_metadesc)
SEOPressSEO title (_seopress_titles_title) and meta description (_seopress_titles_desc)
Rank Math, All in One SEOThe title is not written. The description reaches them through the post excerpt, where their description template uses it.

Quibo sends the fields for all three plugins in every publish. WordPress keeps the ones your active plugin registered and ignores the others, so there is nothing to configure. Empty values are never sent.

  • Jetpack SEO and SEOPress print a custom SEO title as the whole page title, so Quibo sets it only when the article has its own meta title. Otherwise your site's title format applies. Yoast always gets the meta title, or the post title when there is none.
  • Yoast versions before 27.7 do not accept these fields from the REST API. Update Yoast, or set the title and description by hand.

Structured data and unfiltered_html

The JSON-LD goes into the post as a <script type="application/ld+json"> tag inside a Custom HTML block. WordPress keeps that tag only when the connecting user has the unfiltered_html capability:

  • On a single-site install, Administrators and Editors have it. Authors and Contributors do not.
  • On a multisite network only Super Admins have it, so a site Administrator or Editor is not enough.
  • If wp-config.php sets DISALLOW_UNFILTERED_HTML, nobody has it.

Without the capability WordPress removes the tag but keeps its contents, which would show the raw JSON at the end of the article. Quibo checks the saved post and, in that case, removes the block again. The post then has no structured data from Quibo, including the AI-generated marking it carries.

SEO plugins such as Jetpack SEO, Yoast and Rank Math may add their own Article schema in the page head as well. Search engines read both.

Test the connection

After connecting, go to Sites, then your site and click Test connection. Quibo calls GET /wp-json/wp/v2/users/me?context=edit with your credentials (context=edit requires a user with edit capabilities, so an Author role or higher): a 401 or 403 means the username or the Application Password is wrong or has been revoked.

Security

  • The Application Password is encrypted at rest (AES-256-GCM).
  • It's never returned to the browser, never logged, never sent to a third party.
  • Revoke any time from Users, Profile, Application Passwords, Revoke. Publishing stops immediately.
  • Application Passwords cannot create users, install plugins, or change site settings: they're scoped to the user's existing capabilities.