Custom SEO dashboard: the sources, the joins and the build order
Four questions, five sources, one normalisation step that decides whether anybody trusts the page a month later.
Published by AI Knows Us · Updated 12 October 2026
A custom SEO dashboard is one page built on your own extracts rather than a vendor template, and it comes down to three decisions: which four questions it has to answer, which single source owns each number, and how the sources are joined. Get the joins right and everything else is layout. The joins are date, page URL, query, country and device, and the work that makes them hold is normalising URLs before you store anything.
This page is about building one. It assumes you already know what you want to report; it covers where the numbers come from, how to keep them agreeing, and the build order that gets a working page in a week rather than a project that stalls at the connector stage.
Step one: fix the four questions
A dashboard that answers everything gets read by nobody. Write the questions first, in the words the person reading it would use:
- Is organic demand for our commercial pages growing, and where did the change come from.
- Which page groups gained and lost, and is it coverage, position or click through.
- What is close to a breakthrough, meaning queries ranking just below where clicks begin.
- What is broken right now, meaning indexation, speed and errors on pages that matter.
Everything that does not serve one of those four goes on a second page or into a monthly document.
Step two: decide which source owns each number
Half the arguments about dashboards are two sources measuring different things and being asked the same question. Assign ownership once and write it down.
| Source | Owns | Build notes |
|---|---|---|
| Search Console, through the Search Console API | Impressions, clicks, average position and the query to page relationship as Google sees it | The Performance report opens on the past three months and supports hourly, daily, weekly and monthly granularity. Pull daily rows into your own store so your history keeps growing |
| Your analytics platform | What happened after the click: sessions, engaged sessions, conversions, revenue, assisted paths | Landing page is the join key. Normalise it the same way you normalise Search Console page URLs |
| A rank tracker | Position for the specific keywords you chose, by location and device, on a fixed schedule | Keep the tracked list small and stable. A list that changes every month cannot show a trend |
| A crawler | The technical state of the site: status codes, titles, canonicals, indexability, internal links | Export the crawl on a schedule and keep the dates, so you can see what changed after a release |
| Your CRM or order system | Money, and lead quality | Join on a campaign or landing page field you actually populate, and agree one revenue definition with finance |
Step three: normalise before you store
This is the step that separates a dashboard people trust from one they stop opening. Before any row lands in your store, put every URL through the same cleaning rules: force one protocol and one host, decide on trailing slashes and apply it everywhere, lowercase paths if your server treats them that way, strip tracking parameters, and keep a mapping of redirected URLs so a page that moved last year still rolls up to its current group. Then add two columns of your own to every row: page group and query intent group. Those two homemade dimensions are what let you answer the second and third questions above, and no connector provides them.
Step four: the build order
- One sheet, by hand, for a week. Paste in the exports and build the four tiles manually. You will change your mind about three of them, and changing your mind in a spreadsheet is free.
- Nightly extract. Automate the pulls into a store, whether that is a spreadsheet, a database or a warehouse table. Google's usage limits page notes that long date ranges are much more expensive than short ones and advises against requerying the same data, so pull yesterday once and keep it.
- A modelled layer. One table per grain: daily by page, daily by query group, weekly by page group. Dashboards built straight on raw extracts become slow and then abandoned.
- The page itself. Four tiles, one filter set, and a date comparison. Put the definition of each metric in a tooltip or a footnote so nobody has to ask.
- Alerts, not more charts. Send an alert when indexed pages in a group drop, when a tracked keyword leaves the first page, or when clicks to a commercial group fall against the four week average. Alerts are what make a dashboard operational.
Which tool to build it in
| Build | Fits when |
|---|---|
| Spreadsheet with scheduled imports | One site, one person maintaining it, and you want it working this week |
| A free reporting studio with native connectors | Several stakeholders need their own filtered view, and the data volumes are modest |
| Warehouse plus a business intelligence tool | Multiple sites or markets, joins to order data, and a need for history and version control |
| A platform's built in dashboard | You mainly want that platform's own metrics, and your team already lives in it |
Pick on where the maintenance will sit. A dashboard nobody owns stops being accurate in about six weeks, whatever it was built in.
The tiles that belong on an SEO dashboard specifically
- Clicks and impressions by intent group, with commercial pages separated from informational ones, because the mix moves for different reasons.
- Page group table with clicks, impressions, average position and click through, compared with the previous period.
- Striking distance: queries with impressions and an average position just below the click threshold, sorted by impressions.
- Indexation: pages submitted in sitemaps against pages indexed, by group.
- Technical health: non two hundred status codes on pages that receive clicks, plus Core Web Vitals by template.
- Conversions and value from organic landing pages, using the one definition finance agreed.
- Content inventory: pages published and pages updated this period, so output and results sit on the same page.
Why two sources disagree, and how to present it
Search Console counts what happened in Google's results, so its unit is the search impression and the click out of it. Your analytics counts what happened on your site after redirects, consent choices and bot filtering. They answer different questions, and the dashboard should show each one next to the question it owns rather than forcing them into one number. Label the tiles with the source, and the questions about why the totals differ stop arriving.
This page covers building a custom SEO dashboard and keeping its numbers joined. For what to automate and what to keep human in the reporting cycle, read automated SEO reporting. For dashboard layouts across marketing as a whole, read sample marketing dashboard. For what each Search Console number means, read the Search Console guide, and for choosing metrics, SEO KPIs.
What gets asked about Custom SEO dashboard
What should a custom SEO dashboard include?
Four answers: demand trend for commercial pages, winners and losers by page group, queries close to the click threshold, and what is currently broken. Everything else belongs on a second page.
Do I need a data warehouse?
Only when you have several sites or markets, or you want to join search data to orders. One site is well served by scheduled extracts into a spreadsheet or a single database table.
How do I keep Search Console and analytics agreeing?
Give each one the questions it owns, normalise URLs identically on both sides, and label every tile with its source. Then compare trends rather than absolute totals.
How often should it refresh?
Daily for the data, weekly for the human read. Search data arrives with a short delay, so a daily pull of yesterday plus a weekly review matches how decisions actually get made.
What is the most common build mistake?
Storing URLs in whatever form each export happens to use. Clean them once on the way in, keep a redirect map, and add your own page group and intent group columns.
Who should own the dashboard?
One named person, with the metric definitions written down in the same place as the charts. Ownership is the maintenance plan.
The source your dashboard has no connector for yet
There is a channel that none of the five sources above reports. When a buyer asks ChatGPT, Gemini, Perplexity or Claude who to use in your category, or reads Google's AI Overview, an answer is assembled from review text, directory profiles, comparison pages and articles, and a shortlist of named companies comes back. No impression is recorded in Search Console and no session appears in analytics, so a dashboard built only from the usual connectors cannot show whether you are in those answers.
It is measurable in the same way as everything else on the page: a fixed prompt list, run on a schedule, with the names and the cited sources recorded each time. Keep your own company name out of the prompts so the answers come back clean. AI Knows Us measures those answers and the sources behind them.