Site Explorer

One-site review across traffic, search, local visibility, and ads — without leaving SG-Dashboard.

Site Explorer is the SG-Dashboard surface for a deep review of one site. It pulls traffic, search, business-profile, and paid signals into one site-scoped view, so the operator can answer the question what is happening on this site without bouncing between four reporting tools.

Site Explorer sits between Live Analytics (overview-level observation across the portfolio) and the source-specific reporting bodies (GA4, Search Console, Google Business Profile, Ads). It is deep enough for real investigation, light enough to scan in a single session.

What is this for?

Open Site Explorer when attention has narrowed from the portfolio to one specific site and the question is: what is happening on this site?

The surface answers that question by combining the signals that shape the condition of a single property — traffic, search, local visibility, paid — without collapsing them into a single blended score. Each source keeps its meaning; Site Explorer brings them into the same view.

Good use cases

• The Live Analytics view flagged a site that needs a closer look — Site Explorer is the next stop.
• Investigating a traffic dip that may also be visible in search rankings or local presence.
• Reading a campaign's full impact on one site (organic traffic + paid traffic + branded search + business-profile actions).
• Quarterly business review for a single property.
• Preparing a client report that needs a one-site narrative across the major channels.

What NOT to use this for

• Portfolio-level overview — Live Analytics is the right surface for cross-site triage.
• Deep source-specific reporting — open GA4, Search Console, Google Business Profile, or Ads directly when the question is source-specific.
• A blended score across channels. Site Explorer keeps the sources distinct on purpose; it does not produce a single composite number.

How this connects to other features

• Analytics — the broader SG-Dashboard analytics surface. Site Explorer is the per-site lens within that body.
• Reviews — the reputation lens. Reviews data appears in Site Explorer through the business-profile connector.
• Google Analytics 4 integration — traffic source behind the Site Explorer traffic view.
• Google Search Console integration — search source behind the Site Explorer search view.

Before you start

• Confirm the site is registered in SG-Dashboard and the connected sources (GA4, Search Console, Google Business Profile, Ads — whichever apply) show healthy.
• Decide which site to inspect — Site Explorer is one-site at a time by design.
• Pick the date range that matches the question.

Where to find it

SG-Dashboard sidebar → Site Explorer. The landing view prompts for a site selection. Pick a site to load the one-site review.

What Site Explorer shows

Site Explorer assembles up to four blocks for the selected site, depending on which sources are connected.

Each block carries the same date-range and grouping controls as the parent SG-Dashboard, so changing the range or grouping updates every block at once.

Site selection and context framing

Every Site Explorer view is scoped to one site. The site selector lives at the top of the surface; changing it reloads every block for the newly selected site.

The current site context is shown in a header bar so it stays visible while scrolling. This prevents the common "what site am I looking at?" confusion that hits when the operator switches contexts quickly.

Date range and grouping

Site Explorer uses the standard SG-Dashboard date-range control:

• Presets — last 7 days, last 30 days, this month, last month, this quarter, last quarter.
• Custom — pick start and end dates.
• Compare — turn on period-over-period comparison; every block adds a change indicator vs the previous period.

Grouping (daily, weekly, monthly) controls the granularity of the trend charts inside each block.

Site Explorer vs Live Analytics — the boundary

Two related surfaces, distinct scope:

The split is intentional. Live Analytics scans broad; Site Explorer drills deep. Trying to do portfolio triage inside Site Explorer is slow; trying to do deep one-site investigation inside Live Analytics is shallow.

Site Explorer vs source-specific reporting — the other boundary

Site Explorer is deeper than Live Analytics but lighter than the source-specific bodies:

Site Explorer is the right starting point. Drill into the source-specific body when the question goes deeper than the headline signals.

Steps

1. Open Site Explorer.

From the SG-Dashboard sidebar, click Site Explorer. The site selector loads.

2. Pick a site.

Use the site selector at the top. Pick the one site you want to inspect. The four blocks load with the default date range.

3. Set the date range.

Use the date-range control. Pick a preset or a custom range. Every block reloads to match. Turn on Compare if a period-over-period read matters for the question.

4. Scan the headline signals.

Read the four blocks in order — traffic, search, local visibility, paid. Look for outliers vs the previous period and for changes that show up in more than one block (e.g., search impressions and listing searches both up after a campaign).

5. Drill into a source where needed.

Each block has a Open in [source] link. Click it to open the full source-specific reporting body filtered to the same site and date range. Use this when the headline signal raises a deeper question.

What success looks like

After a Site Explorer session:

1. The site selector shows the site under review and the header bar makes that clear.
2. Every connected block shows data for the selected date range; disconnected blocks show a clear "not connected" state.
3. The operator has either a clean read on the site or a specific source-block to drill into next.

What to do if it does not work

Examples

Example 1 — Following up on a Live Analytics flag

The Monday Live Analytics scan showed one site with a 30% traffic drop over the weekend.

Open Site Explorer → pick the flagged site → set range to Last 7 days with Compare on → traffic block confirms the drop and shows it concentrated in organic → search block shows impressions flat but clicks down → drill into Search Console from the search block → top-query check reveals one ranking position loss for a primary term. Investigation handed off to SEO with specifics.

Example 2 — Reading full campaign impact on one site

A two-week campaign ended. The team wants the full read on its top-performing site.

Open Site Explorer → pick the site → set range to the campaign window with Compare on (vs the two weeks prior) → traffic block shows paid sessions up sharply and organic flat → search block shows branded query impressions up (campaign drove brand search) → local visibility block shows direction requests up at the location → paid block ties spend to conversions. Result lands in the campaign retrospective.

Example 3 — Quarterly business review prep

A quarterly review is coming up for one property.

Open Site Explorer → pick the site → set range to Last quarter with Compare on (vs the prior quarter) → screenshot each of the four blocks → drop into the QBR deck with a one-line read per block. The deck has the four-channel picture without needing four separate source-tool exports.

Reading the four blocks together

Each block answers a single-source question. Reading them together is where Site Explorer earns its keep. Three common cross-block patterns to scan for:

• Search up + traffic up — the search investment is paying off. Confirm with branded vs non-branded query split in the search block.
• Paid up + organic flat + branded search up — paid campaign is driving brand awareness. The branded-search lift is the secondary signal.
• Local visibility up + direction requests up + traffic flat — local presence is improving but not converting to web traffic. The cross-channel story may be in-person, not on-site.

The patterns above are starting points, not rules. Real site reads come from operator judgement applied to the four blocks in the surface, not from any single block in isolation.

Compare mode and period selection

Compare mode is the second most-used control after the date range. When on, every block adds a delta indicator vs the previous period of the same length.

Useful patterns:

• Last 7 days vs prior 7 days — week-over-week read for short-cycle work.
• Last 30 days vs prior 30 days — monthly trend without calendar-month alignment noise.
• This month vs same month last year — year-over-year for seasonality-sensitive sites.
• Campaign window vs prior matching window — campaign impact read.

Compare mode adds noise when the site is new or when a connector lost data during the comparison period. Switch it off when the comparison is not meaningful.

Site Explorer in the broader reporting flow

Site Explorer is one stop in a typical SG-Dashboard reporting flow:

1. Live Analytics — portfolio triage; spot the sites that need attention.
2. Site Explorer (this page) — one-site cross-source review on the flagged site.
3. Source-specific reporting (GA4, Search Console, Google Business Profile, Ads) — deep investigation on the source-block that raised the question.
4. Reports / Custom Reports — package the finding for a stakeholder read.

Site Explorer is the middle layer. It is where overview becomes investigation, and where investigation decides which source-specific body to open next.

Edge cases worth knowing

Site Explorer behaviors that surprise first-time users:

• Disconnected blocks are not hidden. A block whose source is not connected still appears, with a clear empty state and a prompt to connect. This is intentional — it tells the operator what the full picture would look like and how to get there.
• Number reconciliation is rarely exact. Site Explorer's traffic block uses GA4's attribution and sampling settings. The source-specific GA4 report uses the same defaults but allows exploration with different settings. Small differences are expected when the source has been re-explored with non-default settings.
• Compare mode is asymmetric for new sites. A site that did not exist in the comparison period shows 100% growth on everything, which is not useful. Switch Compare off for newer sites until the comparison period has real data.
• Some signals lag. Search Console data typically lags by 2-3 days. Local visibility data from Google Business Profile can lag a day or more. Reading "yesterday" in those blocks may show no data — not a bug, the source's update cadence.
• The site context bar persists when scrolling. This prevents reading block data and forgetting which site is loaded — a common mistake when comparing multiple sites in one session.

Frequently asked questions

Why are my Site Explorer numbers different from GA4? Most often: different date range, different attribution model, or different filter (e.g., bots excluded one place but not the other). Confirm the range and settings match before reporting a number mismatch.

Can I look at multiple sites side-by-side in Site Explorer? No — Site Explorer is one site at a time by design. Cross-site comparison lives in Live Analytics or in Custom Reports.

Can I export the Site Explorer view? Site Explorer is interactive on the dashboard, not exportable as a single artifact. For exportable cross-source views, use Custom Reports to assemble the same signals into a report.

What happens to Site Explorer if one of the four sources is rate-limited? The affected block shows a clear partial-data state. The other three blocks remain populated. The block recovers on the next successful pull from the source.

Does Site Explorer count bot traffic? The traffic block inherits GA4's bot exclusion settings. If bots are excluded in GA4, they are excluded here. If they are included in GA4, they are included here.

Can I customize which four blocks appear? The four-block set is fixed in the current Site Explorer surface. The blocks render only for connected sources, so an operator without an Ads connection sees three populated blocks plus the Ads empty state.

Glossary

Field reference — what each block shows at a glance

The block layout is consistent on purpose — once an operator learns one block, the other three behave the same way.

Reading order — how a Site Explorer session typically flows

A typical Site Explorer session runs like this:

1. The operator arrives with a specific site in mind (often after a Live Analytics flag).
2. Open Site Explorer, pick the site, confirm the site context bar shows the right name.
3. Set the date range to match the question (last 7 days for short-cycle, last 30 for monthly, custom for an event window).
4. Turn Compare on if a period-over-period read matters.
5. Scan the four blocks in order — traffic, search, local visibility, paid.
6. Look for cross-block patterns (search + traffic moving together, paid + branded search moving together).
7. Pick the one block that holds the key question and drill into the source-specific report.
8. Take the finding back to the original surface (Live Analytics flag closed, campaign retrospective updated, QBR deck populated).

For a quick health check on a familiar site, the loop is under 2 minutes. For a real investigation that requires drill-in to one or two sources, plan for 15-30 minutes.

Related reading

• Analytics — broader SG-Dashboard analytics surface that contains Site Explorer.
• Reviews — reputation lens; the data feeding the local-visibility block also feeds Reviews.
• Google Analytics 4 integration — connector behind the traffic block.
• Google Search Console integration — connector behind the search block.

Scope

This Reference covers the platform-level shape of site explorer: what the surface is responsible for, how it relates to neighboring surfaces, and the structural boundaries that hold across releases. Operator how-to and per-release change land on the linked operator-facing or changelog surfaces, not here.

Fields