Most people build a custom navigation bar before finding out what the built-in one does. That’s usually an afternoon spent rebuilding something that was already there, and the rebuilt version is generally worse — it doesn’t highlight the current page, it breaks when pages get reordered, and on a phone it lands on top of the content.
So: what Data Studio gives you, how to style it, when overriding it is genuinely the right call, and how to build the custom version with a control most tutorials predate.
The four built-in navigation types in Data Studio
Theme and layout → LAYOUT → Navigation type. Four options, and they’re report-wide.
| Type | What it looks like | Best for |
|---|---|---|
| Left | A collapsible drawer down the left edge. The default. | Reports with more than about five pages, or any grouped hierarchy |
| Tab | A horizontal row across the top | Three to six pages at one level — the most client-report-looking option |
| Top Left | A compact menu anchored top-left | Reports where horizontal space matters more than discoverability |
| Hidden | No navigation at all | Single-page reports, and reports where you’re supplying your own |
All four respect the report theme, which is the first reason to try them before building your own — the built-in navigation picks up your brand colours automatically, and a hand-built one has to be restyled every time the brand changes.
Data Studio navigation is a hierarchy, not a list of pages
This is the feature most people never find, and it’s the one that makes the built-in navigation genuinely good rather than merely adequate.
A Data Studio report’s pages aren’t a flat list. In the Report Pages panel you can group them into sections, add headers as non-clickable labels, and separate blocks with dividers — giving you up to three levels of structure.
So instead of eleven pages in a row, you get something a reader can navigate:
- Summary (page)
- Acquisition (section) — Organic, Paid, Social, Email
- Behaviour (section) — Landing pages, Site search, Journeys
- divider
- Appendix (header) — Definitions, Data sources
Structuring the pages this way also settles most arguments about whether the report is too long. Eleven pages feels like too many; three sections doesn’t.
Style the built-in navigation before replacing it
Before overriding it, check what you can change. The report theme includes a Page navigation style group with its own settings, at the very bottom of the Edit theme panel.
Font family, Active font colour, Font Colour and Background colour. Four fields, and the report menu picks up your brand without you building anything.
Active font colour matters more than it sounds. The built-in navigation highlights the page you’re on. A custom bar built from shapes and text does not, unless you build a variant of every page’s bar with a different item highlighted, which nobody maintains past the second month.
If your objection to the built-in navigation is that it doesn’t match the brand, spend five minutes in Page navigation style before you spend an afternoon replacing it.
Page icons, and what happens when the drawer collapses
Pages can carry icons, set per page in the Report Pages panel. Two behaviours worth knowing before you start:
Icons are top-level only. Pages nested inside a section can’t have them.
It’s all or nothing, visually. When the left drawer is collapsed, icons replace the page numbers. So a report where half the pages have icons collapses into a mix of symbols and digits, which looks like a mistake. Either give every top-level page an icon or give none of them one.
When building your own navigation bar is the right call
Three honest reasons, and a couple that aren’t good enough.
Branding beyond what the four theme settings reach. If the navigation needs a specific typeface, a logo inside it, or a shape the built-in one can’t make, you’re building it.
Mixing report actions with page links. A bar that holds “Overview / Channels / Detail” alongside “Download PDF” and “Reset filters” can’t be the built-in navigation, because that only does pages.
A fixed horizontal bar with a particular layout. Tab navigation is close, but if the design calls for something specific, build it.
Reasons that aren’t good enough: “the built-in one looks generic” — style it first; “I want it at the top” — that’s Tab navigation; “I want icons” — those exist.
Build a custom nav bar with the Button control, not images
Here’s where most tutorials are out of date. The standard recipe on the web is a rectangle with a transparent PNG on top of it, carrying a link. That method predates the Button control, and the button does the same job better.
Add a control → Button. Give it a label, then under Navigation choose Static link and select a page from the report. Style it in the Style tab — background, border, border radius, shadow — and you have a nav item that’s a single object rather than two stacked ones.
Then the two steps everyone forgets, in this order:
- Select the buttons and Make report-level, so the bar appears on every page and is maintained once.
- Set Report-level component position to Top in Theme and layout. Miss this and the bar sits behind your page backgrounds — visible on plain pages, invisible and unclickable on any page with a background shape.
That second step is the single most common reason a hand-built navigation bar “doesn’t work”. The layout and grid guide shows the setting in place, and has a short animation of a report-level component moving out from behind a page background.
Report actions: the toolbar almost nobody builds
A button’s Navigation setting isn’t limited to pages. It can also trigger report actions, and these are genuinely useful in a client report:
- Reset filters — the one worth adding to every report with controls on it, because otherwise people ring you asking why the numbers look wrong after they’ve filtered something and forgotten
- Download report — a PDF button, rather than expecting the reader to find the menu
- Get report link and Invite people — for reports that get forwarded internally
- Refresh data — and if you group it with specific components, it scopes the refresh to those
A row of three page buttons plus a Reset filters button is a better navigation bar than most agencies ship, and it takes about ten minutes. Concretely:
- On page one, Add a control → Button. Label “Overview”, Navigation → Static link → page one.
- Style it: theme accent background, white label, border radius to taste. Get this one exactly right, because the next three are copies.
- Alt-drag it three times to make a row. Relabel and retarget each copy.
- Add a fourth button labelled “Reset filters”, and set Navigation to the Reset filters report action rather than a page.
- Select all four, Arrange → Align → Top, then Distribute horizontally.
- With all four still selected, Arrange → Make report-level.
- Theme and layout → Report-level component position → Top.
- Set Navigation type → Hidden, or the reader gets two menus.
Step eight is the one people forget, and it’s why so many custom bars sit underneath a perfectly good built-in menu doing the same job twice.
The thing this bar still won’t do is tell the reader which page they’re on. If that matters more than the branding — and on a long report it usually does — style the built-in navigation instead and stop here.
Which navigation pattern suits which report
The four types aren’t interchangeable, and the deciding factor is nearly always page count.
| Report | Navigation | Why |
|---|---|---|
| One page | Hidden | Nothing to navigate. A menu on a one-page report suggests there’s more and there isn’t. |
| Two to six pages, one level | Tab | Every destination visible at once, and it reads like a client deliverable rather than a tool. |
| Seven or more, or any grouping | Left | The only type that renders sections and headers, so eleven pages become three groups. |
| Embedded in a portal | Hidden plus your own buttons | The host page usually has its own navigation; two systems compete. |
| A cover in front of a deck-style report | Top Left | Compact enough not to fight the cover, present enough to escape it. |
The pattern that goes wrong most often is Tab navigation on a nine-page report. The tabs wrap or truncate, the client can’t find page seven, and the fix is a navigation type change rather than the custom bar people usually reach for.
Page links that don’t rot when you reorder pages
Four fragility rules, all of them documented by Google and none of them in the tutorials.
Page links bind to an internal ID, not a name. Rename a page and the link survives. Delete and recreate a page — even with the same name — and every link to it breaks silently. This is the one that catches people rebuilding a page they weren’t happy with.
Dynamic links survive reordering. Instead of linking to a specific page, you can link to First, Previous, Next or Last. A previous/next pair in the footer built this way keeps working when you insert a page in the middle; a pair of specific-page links doesn’t.
Link to component scrolls rather than navigates. Useful on a long page, and it can optionally clear the current filters when it lands.
Copy, don’t cut. Cutting a linked component and pasting it elsewhere can break what points at it.
How Data Studio navigation behaves in embeds and on phones
Two surfaces where your navigation behaves differently than you designed it.
Embedded reports put the navigation at the bottom by default, and there’s a Show report navigation in embedded mode option in the embed dialog that controls whether it appears at all. If you’re embedding into a client portal, decide this deliberately — an embedded report with hidden navigation and no custom bar is a one-page report as far as the reader is concerned.
In the mobile app, navigation becomes a bottom sheet reached by tapping the report name. Your carefully positioned horizontal bar is not what people will use there.
What Data Studio navigation can’t do
Stated plainly, because three of these send people down long detours.
Four presets, no more. There’s no fifth navigation type and no way to move the built-in one.
A custom bar has no active state. Nothing tells the reader which page they’re on unless you build per-page variants.
Report-level components sit behind by default. Covered above, and it’s a setting rather than a bug.
A custom navigation bar cannot exist in a responsive report at all. Responsive reports don’t support report-level components, and a nav bar that isn’t report-level is a nav bar you maintain on every page separately. If the report needs to work properly on phones, that constraint arrives before any of the design decisions do.
External links show a redirect notice. A button pointing off-site warns the reader before it leaves, which is Google’s decision rather than yours.
Frequently asked questions
How do I add a navigation menu to a Data Studio report?
It’s already there. Theme and layout → LAYOUT → Navigation type offers Left, Tab, Top Left and Hidden, all of which respect your report theme and highlight the current page. Build a custom bar only when you need branding beyond the four theme settings, or a bar that mixes page links with report actions.
Why is my custom navigation bar invisible or unclickable?
Report-level components sit behind page-level ones by default, so a page background shape covers them. Set Report-level component position to Top in Theme and layout. That single setting is the most common cause.
How do I stop navigation links breaking when I reorder pages?
Use dynamic links — First, Previous, Next and Last — rather than links to specific pages, for anything positional like a previous/next footer. Also know that page links bind to an internal ID, so renaming a page is safe but deleting and recreating one breaks every link to it silently.
Where to go next on report structure
- Data Studio layout and grid: building aligned reports
- Designing a report cover page in Data Studio
- Dashboard design principles for readable reports
- How to build an executive summary page in Data Studio
- Narrative frameworks, and which one your report needs
- How to share and schedule a Data Studio report