How to build WordPress.com dashboards in Metabase

WordPress.com is Automattic's hosted WordPress platform, running your site and serving real traffic statistics through its API. Metabase is where you turn that site data into shared, trustworthy dashboards. This guide covers two complementary paths: a lightweight MCP + CLI route that pulls live data with the WordPress.com MCP server and loads a CSV into Metabase with the Metabase CLI, and a durable pipeline route that syncs WordPress.com stats into a database so you can build dashboards anyone can read.

How do you connect WordPress.com to Metabase?

Most teams combine both routes: use MCP and CLI uploads for a fast first pass, then move recurring site reporting to a warehouse-backed model.

What can you analyze from WordPress.com data in Metabase?

• Views and visitors trend by day — built from daily traffic stats and the related posts and pages, top posts by views, referrers data your connection exposes.
• Top posts and pages by views — built from daily traffic stats and the related posts and pages, top posts by views, referrers data your connection exposes.
• Referrer mix over time — built from daily traffic stats and the related posts and pages, top posts by views, referrers data your connection exposes.
• Publishing cadence vs. traffic response — built from daily traffic stats and the related posts and pages, top posts by views, referrers data your connection exposes.
• Follower and engagement growth — built from daily traffic stats and the related posts and pages, top posts by views, referrers data your connection exposes.

Which WordPress.com dashboards should you build in Metabase?

How do you use the WordPress.com MCP server with the Metabase CLI?

Pair the WordPress.com MCP server 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 daily traffic stats for the trailing 60 days, before the platform's retention window drops them.
• 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 Stats API serves daily rows going back for the life of the site, but only while the plan stays active — a scheduled sync makes that history yours.
• mb upload csv needs an uploads database configured under Admin → Settings → Uploads.

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

{
  "mcpServers": {
    "wordpress-com": {
      "url": "https://public-api.wordpress.com/wpcom/v2/mcp/v1"
    }
  }
}

Available on paid WordPress.com plans. Unlike most hosted site builders, the platform exposes real traffic time-series — views, visitors, likes, and comments per day — through its Stats API, which is exactly the shape a warehouse wants.

# 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 daily-traffic-stats export — creates a table AND a model
mb upload csv --file wordpress-com-daily-traffic-stats.csv --collection root

# Refresh that same table later from a new export
mb upload replace <table-id> --file wordpress-com-daily-traffic-stats.csv

Can you generate a WordPress.com dashboard with AI?

Yes. Use the prompt below with any assistant that can run the WordPress.com MCP server and the Metabase CLI. It works end to end: if WordPress.com 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.com website 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 traffic growth, which posts earn views, referrer mix, and whether publishing cadence moves the numbers from WordPress.com data.

Step 1 — Find or load the data:
- First, check what already exists in Metabase (search for wordpress-com tables and
  models). If durable WordPress.com data is already present — synced from a warehouse or uploaded earlier — use it and skip to Step 2.
- If nothing is there, pull a scoped, summarized export with the WordPress.com MCP server:
  daily traffic stats, plus posts and pages, top posts by views, referrers.
  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.com 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.com Website Overview

Sections:
1. Executive summary: Views last 30 days; Visitors; Views per visitor;
   Posts published this month.
2. Traffic: Views and visitors by day; week-over-week change.
3. Top content: Top posts and pages by views; first-28-day views for new posts.
4. Referrers: Views by referrer group; search vs. social vs. direct mix.
5. Publishing response: Posts published vs. views by week, by author.

Note: WordPress.com Stats reports traffic only — there is no store or order
data here, so do not add commerce cards.

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.com data into a database or warehouse?

For dashboards that need history and reliability, land WordPress.com stats and entities in a database first, then connect Metabase to that database.

Connector options

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

No managed connector exists — schedule a small script against the Stats API (stats/visits returns daily views and visitors) and the posts endpoints, landing daily rows in your warehouse alongside content metadata.

Notes

• Land raw entity tables first, then build clean Metabase models on top.
• Normalize site, date, sessions or views, orders, and revenue fields.
• Keep platform stats (views, sessions) separate from measured analytics tools' numbers — definitions differ, and gaps are normal.

How should you model WordPress.com data in Metabase?

Core tables

Modeling advice

• Build a clean site_traffic_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.com metrics should you track in Metabase?

What SQL powers WordPress.com dashboards in Metabase?

These assume WordPress.com data synced into a warehouse (PostgreSQL dialect). Adjust table and column names to match your pipeline.

SELECT
  stat_date,
  views,
  visitors,
  ROUND(1.0 * views / NULLIF(visitors, 0), 2) AS views_per_visitor
FROM wpcom_stats_daily
WHERE stat_date >= CURRENT_DATE - INTERVAL '90 days'
ORDER BY 1;

SELECT
  p.title,
  p.author,
  p.published_at::date AS published,
  SUM(t.views) AS views_28d
FROM wpcom_top_posts_daily t
JOIN wpcom_posts p ON p.post_id = t.post_id
WHERE t.stat_date >= CURRENT_DATE - INTERVAL '28 days'
GROUP BY 1, 2, 3
ORDER BY views_28d DESC
LIMIT 25;

WITH published AS (
  SELECT date_trunc('week', published_at) AS week, COUNT(*) AS posts
  FROM wpcom_posts
  WHERE status = 'publish'
  GROUP BY 1
),
traffic AS (
  SELECT date_trunc('week', stat_date) AS week, SUM(views) AS views
  FROM wpcom_stats_daily
  GROUP BY 1
)
SELECT
  t.week,
  COALESCE(p.posts, 0) AS posts_published,
  t.views
FROM traffic t
LEFT JOIN published p ON p.week = t.week
ORDER BY t.week;

What are common mistakes when analyzing WordPress.com in Metabase?

Related

Related analytics

Related dashboards

Related integrations

FAQ