How to build WordPress dashboards in Metabase

WordPress is the open-source CMS behind roughly 40% of the web, self-hosted on your own server with a MySQL database. Metabase is where you turn that site data into shared, trustworthy dashboards. This guide covers three complementary paths: a direct database connection to the MySQL instance WordPress runs on, a lightweight MCP + CLI route that pulls live data with the WordPress MCP Adapter and loads a CSV into Metabase with the Metabase CLI, and a durable pipeline route that syncs WordPress stats into a database so you can build dashboards anyone can read.

How do you connect WordPress to Metabase?

Self-hosters should start with the database route; the MCP + CLI and pipeline routes cover hosted setups and cross-source joins.

How do you connect Metabase directly to the WordPress database?

Point Metabase straight at the WordPress MySQL database: wp_posts, wp_comments, wp_users, wp_terms — and if you run WooCommerce, order tables like wp_wc_order_stats — become queryable with zero ETL.

• Add the MySQL instance under Admin → Databases in Metabase — use a read-only user, and prefer a read replica for busy production sites.
• Build Metabase models on top of the raw tables (filter out revisions, autosaves, and internal statuses once), and point every question at the models.
• Version-pin your expectations: CMS core upgrades can change internal schemas, so re-check models after major updates.

What can you analyze from WordPress data in Metabase?

• Publishing velocity by author and category — built from posts and publishing activity and the related comments, authors, categories and tags data your connection exposes.
• Content inventory and freshness audit — built from posts and publishing activity and the related comments, authors, categories and tags data your connection exposes.
• Comment engagement by post and topic — built from posts and publishing activity and the related comments, authors, categories and tags data your connection exposes.
• WooCommerce revenue next to content activity — built from posts and publishing activity and the related comments, authors, categories and tags data your connection exposes.
• Draft backlog and time-to-publish — built from posts and publishing activity and the related comments, authors, categories and tags data your connection exposes.

Which WordPress dashboards should you build in Metabase?

How do you use the WordPress MCP Adapter with the Metabase CLI?

Pair the WordPress MCP Adapter with the Metabase CLI for fast, hands-on analysis. MCP is useful for scoped lookups and summarized exports; the Metabase CLI's upload command loads CSV data into Metabase and creates a ready-to-query table and model.

Example workflow

• Ask the MCP server for a summary of posts and publishing activity for the last 90 days, by status and author.
• Export the result as CSV, keeping stable IDs, statuses, and dates as columns.
• Run mb upload csv to load it into Metabase as a table and model, then build questions and dashboards on top.

Be honest about the limits

• MCP lookups are excellent for exploration, not scheduled reporting.
• A CSV upload is a snapshot; refresh it with mb upload replace or move to a durable route for real history.
• The database holds full history already — the CSV route is only a bridge until Metabase can reach MySQL directly.
• mb upload csv needs an uploads database configured under Admin → Settings → Uploads.

How do you set up WordPress MCP and the Metabase CLI?

{
  "mcpServers": {
    "wordpress": {
      "command": "npx",
      "args": ["-y", "@automattic/mcp-wordpress-remote"],
      "env": {
        "WP_API_URL": "https://yoursite.com",
        "WP_API_USERNAME": "your-username",
        "WP_API_PASSWORD": "your-application-password"
      }
    }
  }
}

The MCP Adapter plugin comes from the WordPress AI team and exposes the new Abilities API over MCP; the @automattic/mcp-wordpress-remote proxy (Node 22+) bridges it to stdio clients. The older Automattic/wordpress-mcp plugin is being deprecated in its favor.

# Install the Metabase CLI
npm install -g @metabase/cli

# Log in (opens your browser; requires Metabase v62+)
mb auth login --url https://your-metabase.example.com

# Load a posts-and-publishing-activity export — creates a table AND a model
mb upload csv --file wordpress-posts-and-publishing-activity.csv --collection root

# Refresh that same table later from a new export
mb upload replace <table-id> --file wordpress-posts-and-publishing-activity.csv

Can you generate a WordPress dashboard with AI?

Yes. Use the prompt below with any assistant that can run the WordPress MCP Adapter and the Metabase CLI. It works end to end: if WordPress tables already exist in Metabase it analyzes those; otherwise it pulls scoped, summarized data over MCP, loads it with mb upload csv, then builds the dashboard and caveats any metric that needs missing history.

Create a polished Metabase dashboard for WordPress content & site analytics.
Work end to end: get the data into Metabase if it isn't there yet, then build.

Goal: Help site and content owners understand publishing velocity, content inventory health, reader engagement, and WooCommerce revenue where the store tables exist from WordPress data.

Step 1 — Find or load the data:
- First, check what already exists in Metabase (search for wordpress tables and
  models). If Metabase is already connected to the WordPress database, use those tables directly — that's the best route.
- If nothing is there, pull a scoped, summarized export with the WordPress MCP Adapter:
  posts and publishing activity, plus comments, authors, categories and tags.
  Write each result to a CSV, then load it with the Metabase CLI — run
  "mb upload csv --file <export>.csv" so each upload creates a table and a
  ready-to-query model. Use "mb upload replace <table-id> --file <export>.csv"
  to refresh an existing table instead of creating duplicates.

Step 2 — Inspect before querying:
Do not assume exact table or column names. Inspect available content types,
statuses, dates, and whether daily history exists before creating trend cards.

Important:
- Build on whatever data is present; don't claim Metabase connects natively to
  the WordPress API — it reads a database or CLI-uploaded tables.
- Exclude revisions, autosaves, and test entries from headline content counts.
- Only compute rates (conversion, open rate, paid share) when both numerator
  and denominator exist in the data.
- A single CSV is a point-in-time snapshot: only build trend cards if there is
  a usable date column or multiple periods have been uploaded.

Dashboard title: WordPress Content & Site Overview

Sections:
1. Executive summary: Posts published this month; Draft backlog; Approved
   comments; Orders and net revenue (only if WooCommerce tables exist).
2. Publishing: Output by week by author; time from draft to publish; category mix.
3. Inventory: Posts and pages by status and age; stale-content table.
4. Engagement: Comments per week; most-commented posts; user registrations.
5. Commerce: Orders, net revenue, and AOV by week — skip this section entirely
   if the WooCommerce tables are absent.

Filters: Date range, Content type/Collection, Status, Author/Editor.

Output: Build the dashboard if you have permission; otherwise provide the exact
questions, SQL, model definitions, and layout. Include caveats for any metric
that cannot be calculated from the available data.

How do you sync WordPress data into a database or warehouse?

Self-hosted installs may not need a sync at all — connect Metabase to the database. Sync when you're on a hosted plan, or when WordPress data should land next to analytics and revenue data in a shared warehouse.

Connector options

• Managed ETL — use a connector when one covers the objects you need.
• Custom pipeline — use the WordPress REST API for control over grain, fields, and refresh cadence.
• MCP + CSV — use this for quick exploration and one-off slices.

The Airbyte WordPress source and Fivetran's WordPress Lite connector sync posts, pages, comments, and users over the REST API — useful for hosted setups where you can't reach MySQL. When you can reach the database, the direct connection makes them unnecessary.

Notes

• Land raw entity tables first, then build clean Metabase models on top.
• Normalize content type, status, author, created and published dates fields.
• Keep platform stats (views, sessions) separate from measured analytics tools' numbers — definitions differ, and gaps are normal.

How should you model WordPress data in Metabase?

Core tables

Modeling advice

• Build a clean content_activity_daily model with consistent columns, so dashboards survive schema changes and plugin swaps.
• Filter out revisions, autosaves, drafts-of-drafts, and internal test entries once, in the model — not in every question.
• Normalize URLs (lowercase, no protocol, no trailing slash) so CMS content joins cleanly to analytics and Search Console data.
• Store dates in UTC and convert at display time; CMS installs often run in site-local timezones.

Which WordPress metrics should you track in Metabase?

What SQL powers WordPress dashboards in Metabase?

These run against WordPress's own MySQL schema, shown in PostgreSQL dialect — MySQL needs minor changes such as DATE_FORMAT in place of date_trunc.

SELECT
  date_trunc('week', post_date) AS week,
  COUNT(*) AS posts_published
FROM wp_posts
WHERE post_type = 'post'
  AND post_status = 'publish'
GROUP BY 1
ORDER BY 1;

SELECT
  post_title,
  post_date::date AS published,
  post_modified::date AS last_updated,
  comment_count
FROM wp_posts
WHERE post_type IN ('post', 'page')
  AND post_status = 'publish'
  AND post_modified < CURRENT_DATE - INTERVAL '12 months'
ORDER BY post_modified
LIMIT 50;

SELECT
  date_trunc('week', date_created) AS week,
  COUNT(*) AS orders,
  ROUND(SUM(net_total), 2) AS net_revenue,
  ROUND(SUM(net_total) / NULLIF(COUNT(*), 0), 2) AS avg_order_value
FROM wp_wc_order_stats
WHERE status = 'wc-completed'
GROUP BY 1
ORDER BY 1;

What are common mistakes when analyzing WordPress in Metabase?

Related

Related analytics

Related dashboards

Related integrations

FAQ