Handling Multiple Gmail Accounts for Google Search Console using Hobo SEO Dashboard

Multi-Account Client Management – A Definitive Guide

This report provides a definitive guide to architecting the Hobo SEO Dashboard for effective multi-account client management.

It establishes that the tool’s architecture is intrinsically and deliberately bound to a single Google Account, a pivotal identity defined herein as the “Admin Master Account.“

This design choice is not a limitation but a foundational feature that guarantees the tool’s core value proposition: absolute data privacy and user control. All operations, from data fetching to report distribution, are executed under the exclusive authority of this single account.

The analysis details two primary operational architectures.

Standard Operating Model

The first, the Standard Operating Model, represents the tool’s intended and most efficient use case: a single dashboard instance managing a large portfolio of clients whose Google Search Console access has been consolidated under one Admin Master Account. This model leverages an iterative, resource-frugal design to deliver powerful automation at scale without incurring API costs.

Parallel-Instance Architecture

The second, the Parallel-Instance Architecture, is presented as the necessary and correct solution for managing clients whose access is fragmented across multiple, separate Google Accounts. This report validates this approach as a standard architectural pattern for navigating cross-account data access challenges within the Google Cloud ecosystem.

It provides a meticulous, step-by-step implementation guide for setting up multiple, independent dashboard instances, with a critical emphasis on credential isolation to ensure a successful and error-free deployment.

Ultimately, this report concludes that while the parallel-instance model is a functionally necessary strategy for managing segregated accounts, it introduces significant operational overhead and data fragmentation.

Therefore, the strategic imperative for any agency aiming for efficiency, scalability, and deep analytical capability is the systematic consolidation of all client permissions into a single Admin Master Account.

This aligns agency workflow with the tool’s most powerful design, unlocking its full potential as a streamlined and scalable SEO management platform.

Understanding the Admin Master Account

To effectively architect the Hobo SEO Dashboard for any client management scenario, it is essential to first comprehend its core architectural principle: the tool is technically and philosophically bound to a single Google Account identity. This report defines this pivotal identity as the “Admin Master Account.”

This account is not merely a login; it is the specific Google Account that owns the Hobo SEO Dashboard Google Sheet file, and this ownership constitutes the absolute and indivisible source of authority for all of the tool’s operations.

Every automated action, from fetching Google Search Console data via its API to distributing client reports through Gmail, is executed under the identity and permissions granted exclusively to this one account.

The dashboard’s design is fundamentally different from that of a typical third-party Software-as-a-Service (SaaS) platform, where users log into a vendor’s centralised system.

Instead, the Hobo SEO Dashboard is a system “installed in your own account” that operates “entirely within the user’s Google ecosystem”.

This design choice is paramount, as it prioritises data privacy and user control above all else. The tool is aptly described as “your own robot that runs entirely on Google Sheets and Gmail”, a description that powerfully reinforces the concept that it acts as an automated proxy for one specific user – the Admin Master Account.

This single-identity architecture is the very foundation of the tool’s most lauded features.

The claims of being “100% private” and ensuring all “data remains under the user’s control” are not marketing statements but direct, verifiable consequences of this design.

The system is secure precisely because it is sandboxed within a single Google Account’s permissions framework. It does not possess the technical capability to authenticate, reach into, or even be aware of other Google identities during its execution.

What might be perceived by a new user as a limitation – the inability to natively handle multiple Google Account logins – is, in fact, the foundational security feature that guarantees the privacy and data sovereignty promised by its developer.

To allow the tool to access multiple accounts would require it to operate outside this secure sandbox, fundamentally breaking the privacy model that is its core strength.

This reframes the question from “Why can’t the tool do this?” to an understanding that “This is why the tool is secure and private.”

This architecture places the user in a role more akin to a system administrator than a simple end-user. The responsibility for the entire operational stack – the Google Sheet file, the embedded Google Apps Script, the linked Google Cloud Platform (GCP) project, and the associated API credentials – rests with the owner of the Admin Master Account.

Unlike a SaaS tool where the vendor manages the backend infrastructure, the Hobo setup process requires the user to perform administrative tasks such as creating and linking a GCP project, enabling the necessary APIs, and managing the OAuth authorisation flow.

This implies a higher level of user responsibility and technical engagement is both expected and required for successful implementation and troubleshooting.

The technical link between the dashboard and the Admin Master Account is a rigid and unbreakable chain of command established during the initial setup process. This chain operates through a precise sequence of delegation and authority:

Ownership: The Admin Master Account is the definitive owner of the master Google Sheet file that constitutes the Hobo SEO Dashboard. This ownership is the primary source of all subsequent permissions.
Script Execution: The powerful Google Apps Script embedded within the sheet, which contains all the tool’s logic, runs with the permissions explicitly granted to it by the sheet’s owner (the Admin Master Account) during the initial authorisation prompts.
GCP Project Linkage: The Apps Script project within the sheet must be linked to a single Google Cloud Platform (GCP) Project. This is a critical and mandatory step in the setup process, and the GCP project must also be owned by, or at a minimum fully accessible to, the Admin Master Account.
API Authorisation: All Application Programming Interface (API) calls—to the Google Search Console API, Google Drive API, or Google Sheets API—are subsequently made through this linked GCP project. These calls use the OAuth 2.0 credentials generated for the Admin Master Account during the authorisation step. The setup guides explicitly require enabling the Google Search Console API within this specific GCP project, which solidifies the immutable 1-to-1 relationship between a single dashboard instance and a single Google identity.

Centralised Management for Consolidated Accounts

The Hobo SEO Dashboard operates at its peak efficiency and power within its intended use case: a centralised command centre for managing a large portfolio of client properties, all of which are accessible by a single Google Account.

This directly addresses the common agency scenario of managing one account with, for example, 20 clients. In this situation, deploying a single instance of the Hobo SEO Dashboard is not only sufficient but is the correct and intended method of operation.

There is no architectural or practical need for multiple sheets or dashboard instances.

The dashboard is expressly designed to “autonomously rotate through every client in your Search Console account”.

The workflow is initiated through the Import Search Console Clients function, located under the Hobo Admin menu within the Google Sheet.

When executed, this script performs a comprehensive scan of all website properties associated with the Admin Master Account in Google Search Console. It then automatically populates the Hobo SEO Dashboard Clients tab within the dashboard sheet with this information.

The “Clients” tab is more than a simple list; it is the central nervous system of the entire automation system.

Each website property discovered in Google Search Console is treated as a distinct “client” entity, with its specific configuration data, reporting settings, and status stored in a unique column within this tab.

Mastering the configuration options within the “Clients” tab is equivalent to mastering the tool’s full automation capabilities, as the entire iterative reporting process is driven by the data and settings contained within it.

The tool is architected to handle a significant volume of clients within this single-instance model, far exceeding the 20-client scenario. The “Clients” tab contains a global setting, Hobo SC – Number of Sites to import, which has a default or example value of 500 – although it can import the full 1000 accounts from Search Console if you have that many.

This built-in parameter is a clear indicator that the system was engineered from the ground up for agency-level scale, capable of managing hundreds of client properties from a single control plane.

Once the clients are imported and configured in the “Clients” tab, activating the “Automated Reporting” function initiates the autonomous process.

The system then initiates its iterative workflow, cycling through each client one by one to generate detailed reports based on Google Search Console data, Screaming Frog crawl files (if the integration is configured), and the built-in Hobo Premium SEO checklists, housed in the Hobo SEO Audit tab.

A crucial aspect of this operational model is that its processing logic is deliberately iterative, not concurrent. The documentation consistently describes the dashboard as “cycling through” and “rotating through” the client list.

This sequential, one-at-a-time processing logic is a sophisticated engineering decision, not a sign of an underpowered system.

It is designed to be “very frugal” with resources and to “stay well within Google’s free API thresholds”.

Google’s APIs, including the Google Search Console API, are subject to daily usage quotas. A system that attempted to process hundreds of clients concurrently would generate a massive burst of simultaneous API calls, which would rapidly exhaust the free daily quota, potentially incurring costs or causing the entire process to fail.

By processing one client at a time, the dashboard intelligently spreads its API calls over a longer period, ensuring it remains comfortably within Google’s generous free limits.

This design choice intentionally trades raw processing speed for immense cost-efficiency and operational reliability. The trade-off is that a full reporting run for a large number of clients will take a considerable amount of time to complete. However, the overwhelming benefit is that the process runs reliably, autonomously, and for free, which is a far more valuable proposition for its target audience of SEO professionals and agencies.

This architecture is precisely what enables a single dashboard instance to efficiently and economically manage a large roster of clients over time without hitting API limits or requiring paid upgrades.

Navigating Fragmented Client Access Across Multiple Gmail Accounts

When an agency’s client website access is distributed across multiple, separate Google Accounts that cannot be consolidated, the single-identity architecture of the Hobo SEO Dashboard imposes a clear and non-negotiable constraint.

This directly addresses the more complex scenarios where a user might have, for example, two different Gmail accounts, each with exclusive access to a distinct set of 15 clients. In this case, a single dashboard instance is fundamentally insufficient.

A dashboard instance that is owned by and authorised under “Master Account 1” will only be able to discover, access, and report on the 15 Google Search Console properties accessible to that specific account. It will have no awareness of, or technical access to, the 15 properties associated with “Master Account 2.”

Therefore, for this fragmented access scenario, the answer is unequivocally yes: two separate sheets – or more accurately, two separate and independent dashboard instances – are required.

This is the correct and necessary architectural solution if you have 2 Gmail accounts, both with access to different sets of Search Console Accounts. The proposition that one would “effectively have 2 dashboards running – one for each account” is the precise strategy required by the tool’s fundamental design when Google Search Console access cannot be centralised into a single identity.

The root cause of this constraint lies in the dashboard’s complete dependency on the Google ecosystem; its functionality is “entirely reliant on Google’s services (Sheets, Apps Script, Drive, GSC API)”.

The tool has no built-in mechanism for multi-account authentication, nor can it pause its execution to prompt a user to log in to a different Google account.

The Google Apps Script that powers the dashboard runs under the singular authority of the Admin Master Account that owns the sheet. It operates with a single, non-transferable identity token for its entire execution lifetime and can only access the resources that this specific user has been granted permission to view.

The script has no concept of a “different user” and therefore cannot cross the security boundary between two separate Google Accounts.

This challenge is not a unique flaw or oversight in the Hobo SEO Dashboard but is a common architectural hurdle when working within the broader Google Cloud ecosystem.

This constraint is fundamentally a matter of identity and authorisation, not data transfer. For instance, users of Google’s own Looker Studio (formerly Data Studio) face the exact same problem when attempting to build a consolidated report from “Google Analytics accounts scattered between different Google accounts”.

The standard and recommended solution in that context is to have the disparate data sources shared with a central “master report” account, which then acts as the single hub for data access and visualisation.

This powerful parallel demonstrates that the constraint is not a design flaw in the Hobo tool but a fundamental characteristic of how Google’s permission-based cloud ecosystem is structured for security and privacy.

Consequently, the solution of running parallel dashboard instances should not be viewed as a “workaround” for a broken feature.

Instead, it should be understood as the standard and accepted architectural pattern required to solve this common cross-account data access problem within Google’s environment. By implementing this pattern, the user is not hacking the tool but is correctly applying a standard cloud architecture principle to a well-understood problem.

This perspective boosts confidence in the solution and validates the user’s approach as both logical and technically sound.

The Parallel-Instance Architecture – A Definitive Implementation Guide

To successfully manage clients whose Google Search Console access is spread across two or more separate Google Accounts, a meticulous and disciplined setup of parallel, independent Hobo SEO Dashboard instances is required.

The following implementation plan details the necessary steps, placing a heavy emphasis on the critical need for credential isolation to ensure a successful and error-free deployment. Each instance must be treated as a full, atomic system—a self-contained unit with its own sheet, script, cloud project, and authorisations.

One is not simply “connecting” a new sheet; one is building a completely new, independent system from scratch for each account.

Phase 1: Establishing Dashboard Instance A (Master Account 1)

This phase establishes the first of the two parallel systems.

Prepare the Environment: The most critical step for preventing setup errors is to ensure strict credential isolation. Log into a Google Chrome profile that is exclusively signed into Master Account 1. Using dedicated browser profiles for each account is the most reliable method to prevent the browser from confusing credentials during the authorisation process.
Create the Dashboard: Make a fresh copy of the master Hobo SEO Dashboard Google Sheet template. It is vital to name this copy clearly to avoid future confusion, for example, Hobo Dashboard – Account A. This new sheet will be owned by Master Account 1.
Set Up the Google Cloud Platform (GCP) Project: While logged in as Master Account 1, navigate to the Google Cloud Console and create a completely new GCP project. Name it accordingly to maintain clarity, such as Hobo Dashboard A – GCP.
Enable APIs: Within this new GCP project (Hobo Dashboard A – GCP), navigate to the “APIs & Services” > “Library”. Search for and enable the following three APIs: “Google Search Console API,” “Google Drive API,” and “Google Sheets API”.
Configure the OAuth Consent Screen: Navigate to “APIs & Services” > “OAuth consent screen”. Configure the screen as required by Google’s prompts. This will likely involve setting the User Type, providing an application name (e.g., Hobo Dashboard Automation), and adding the user support email (Master Account 1’s email address).
Link the Sheet to the GCP Project: Open the Hobo Dashboard – Account A Google Sheet. Go to the menu Extensions > Apps Script. In the Apps Script editor window, click the “Project Settings” (gear icon ⚙️) on the left-hand menu. Scroll down to the “Google Cloud Platform (GCP) Project” section. Click “Change Project” and enter the Project Number (not the Project ID or Name) from the Hobo Dashboard A – GCP project created in step 3. Click “Set Project” to establish the link.
Initialise and Authorise: Return to the spreadsheet. Run an initial function from the menu, such as Hobo Admin > Report Scheduler > Activate Automated Reporting. This will trigger Google’s authorisation prompts. Follow the on-screen steps carefully, selecting Master Account 1 and granting the script all the necessary permissions it requests. Once complete, this dashboard instance is now live and will begin to import and process the 15 clients associated with Master Account 1.

Establishing Dashboard Instance B (Master Account 2)

This phase repeats the process for the second account, with an absolute emphasis on environmental isolation.

CRITICAL – Isolate the Environment: This is the single point of failure in a multi-instance setup. Log out of all Google accounts in the browser. It is strongly recommended to use a completely different and separate Chrome profile or, at a minimum, a fresh Incognito window. Log in exclusively as Master Account 2. Failure to properly isolate the browser session will likely cause the new instance to incorrectly link to the first account’s credentials, leading to a confusing state that is difficult to debug.
Create the Second Dashboard: Make a fresh copy of the original Hobo SEO Dashboard template file. Do not make a copy of Hobo Dashboard – Account A. Name this new sheet distinctly, for example, Hobo Dashboard – Account B. This sheet will be owned by Master Account 2.
Create a Separate GCP Project: While logged in as Master Account 2, navigate to the Google Cloud Console and create a second, completely separate GCP project. Name it distinctly, such as Hobo Dashboard B – GCP.
Enable APIs: In this second GCP project, repeat the process of enabling the “Google Search Console API,” “Google Drive API,” and “Google Sheets API.”
Configure the OAuth Consent Screen: Configure the OAuth consent screen for this second project, using Master Account 2’s email address where required.
Link the Project: In the Apps Script editor of the Hobo Dashboard – Account B sheet, link it to the new Hobo Dashboard B – GCP project using its unique Project Number.
Initialise and Authorise: In the second spreadsheet, run the Activate Automated Reporting function and complete the authorisation prompts, this time selecting and authorising with Master Account 2. This instance will now import and process the 15 clients associated with Master Account 2, operating completely independently of Instance A.

Operational Considerations for Parallel Management

Implementing this architecture results in two completely separate and parallel data environments. It is crucial to be aware of the following operational realities:

Data Silos: There will be two of everything: two “Clients” tabs, two sets of generated reports in two different Google Drive accounts, and two distinct sets of “Winners and Losers” data. There is no built-in method to merge or consolidate this data automatically across the two instances. Any cross-portfolio analysis will require manual data extraction and consolidation.
Screaming Frog Integration: If using the Screaming Frog integration, it is vital to maintain two separate and parallel folder structures within the respective Google Drive accounts of Master Account 1 and Master Account 2. The script in Instance A must be pointed to a folder in Drive A, and the script in Instance B to a folder in Drive B. This prevents Instance A from accidentally processing crawl files intended for Instance B, and vice versa.
Independent Automation: Each dashboard instance will have its own independent set of automation triggers (e.g., for weekly or monthly report generation). These time-based schedules are managed separately within each sheet’s respective Apps Script project and will run entirely independently of one another.

Operational Realities and Strategic Workflow Management

While the parallel-instance architecture is the functionally necessary solution for managing clients across segregated Google accounts, its implementation introduces some operational complexity and strategic limitations.

Adopting this model solves the immediate technical problem of data access at the cost of creating long-term, compounding management overhead. This is a form of “management debt,” where the initial solution creates an ongoing “interest payment” in the form of increased manual effort, monitoring, and potential for error.

The day-to-day realities of this model involve managing two or more of everything. There are multiple “Clients” tabs to configure and maintain, separate automation schedules to monitor, and distinct sets of generated reports to track. If the Screaming Frog integration is used, this complexity extends to maintaining parallel folder structures in separate Google Drive accounts to avoid data cross-contamination. Each new client added to a fragmented account further deepens this management debt, increasing the time and attention required to keep the systems running smoothly.

Perhaps the most significant strategic cost of this data siloing is the inherent inability to perform holistic, cross-portfolio analysis.

An agency’s competitive advantage often stems from its ability to identify trends, patterns, and performance benchmarks across its entire client base. For example, an agency might want to analyse the impact of a recent Google algorithm update across all its e-commerce clients. With a consolidated dashboard, this analysis is straightforward.

With parallel instances, a query comparing a client from Instance A to a client from Instance B is impossible without tedious manual data extraction, copying, and pasting. The architecture itself becomes a barrier to strategic thinking and proactive, data-driven client management.

The following table offers a clear, side-by-side comparison of the required parallel-instance architecture versus the ideal consolidated model, starkly illustrating the trade-offs involved. This comparison serves as a powerful decision-making tool, visually articulating that the upfront effort required to achieve consolidation is a strategic investment that pays substantial dividends in operational efficiency and analytical capability.

Factor	Consolidated Master Account (Ideal State)	Parallel-Instance Architecture (Required State)
Setup Complexity	Low: A single, one-time setup process for one sheet and one corresponding GCP project.	High: A repetitive and meticulous setup process is required for each account, demanding careful credential isolation to prevent critical errors.
Management Overhead	Low: A single “Clients” tab to manage, one set of generated reports, one automation schedule to monitor. Centralised control.	High: Two or more of everything to monitor and manage (dashboards, client lists, schedules, Drive folders). Increased risk of configuration errors and inconsistencies.
API Quota Management	Centralised: All API usage is tracked within a single GCP project, simplifying monitoring and troubleshooting.	Decentralised: API usage is split across multiple GCP projects, requiring separate monitoring for each instance to ensure quotas are not exceeded.
Reporting Consolidation	Native: All client data resides within a single spreadsheet, allowing for easy cross-client analysis, comparison, and the creation of agency-level summary reports.	Manual: Data is siloed in separate, disconnected spreadsheets. Consolidating reports for a holistic agency view requires manual export, import, or copy-paste procedures.
Cross-Client Analysis	Effortless: The ability to easily compare performance metrics, “Winners and Losers” data, and trends between any clients in the portfolio.	Prohibitive: It is not possible to directly compare clients from different instances within the tool. This severely limits strategic, cross-portfolio insight generation.
Cost Implications	Minimal: The tool is designed to be frugal and stay within Google’s free API tiers. Potential costs are limited to external factors like a Screaming Frog licence.	Minimal: The cost profile per instance is the same as the consolidated model, but requires more diligent monitoring across multiple GCP projects if client numbers grow significantly.

The Path to Consolidation and Scalability

This analysis leads to a clear and unequivocal primary recommendation: the most efficient, scalable, and manageable long-term strategy is to consolidate Google Search Console access into a single, designated Admin Master Account.

This involves systematically requesting that all clients, regardless of their current access structure, grant “Full” or “Owner” level access in Google Search Console to the one chosen Admin Master Account email address. Achieving this consolidation completely eliminates the management debt, data siloing, and setup complexity inherent in the parallel-instance model. It aligns the entire agency workflow with the Hobo SEO Dashboard’s intended and most powerful operational design, transforming it from a series of disconnected reporting tools into a single, unified automation platform.

The primary barrier to achieving this ideal state is often not technical but procedural and relational. It requires effective client communication and relationship management. The agency must be able to successfully articulate the need for consolidated access. This report can empower that conversation by providing the business case. The agency can explain to its clients: “To leverage our secure, privacy-first automation platform and provide you with the most efficient service, we require ‘Full’ Google Search Console access to be granted to our central agency administration account. This allows our automated systems to work on your behalf. Importantly, this process is built on a tool that is ‘100% private’ and ensures all your data remains securely under your control within Google’s own ecosystem”.

This approach reframes a technical request into a clear client benefit rooted in efficiency and security.

While pursuing consolidation, it is a matter of sound agency practice to remain aware of potential platform-level limitations. Although the Hobo dashboard’s internal import limit is high (e.g., 1000 sites) , the underlying Google services can have their own account or property limits.

For example, it has been noted in other contexts that Google Analytics has account limits. While this is not a direct limitation of the Hobo tool, maintaining an awareness of the broader platform’s scaling rules is a prudent practice for any growing agency planning for the long term.

If consolidation is not immediately feasible due to legacy client agreements or other constraints, adhering to a strict set of best practices is essential for managing parallel instances and mitigating risk.

These practices should be viewed as a temporary bridge to the desired future state of consolidation, not as a permanent destination. They are survival tactics for making a suboptimal architecture manageable.

Secondary Recommendation – Best Practices for Parallel Operations

Strict Naming Conventions: Implement and enforce unambiguous naming conventions for all related assets. This creates clarity and reduces the risk of human error. For example:

Google Sheets: Hobo_Dashboard_[Client_Group_A], Hobo_Dashboard_
GCP Projects: GCP_Hobo_A, GCP_Hobo_B
Google Drive Folders: SF_Crawls_Account_A, SF_Crawls_Account_B

Mandatory Use of Dedicated Browser Profiles: The single most effective technique for preventing setup and authorisation errors is the mandatory use of dedicated Google Chrome Profiles for each Admin Master Account. This keeps cookies, login sessions, and OAuth authorisations strictly separate, preventing the most common and frustrating credential-related setup failures.
Maintain Internal Documentation: Create and maintain a simple internal document, such as a shared spreadsheet, that acts as a “master key” or manifest. This document should explicitly track which dashboard instance (sheet name), GCP project (project number), and Google Drive folder corresponds to which Admin Master Account and, by extension, which set of clients. This becomes an invaluable and time-saving reference as the number of clients, accounts, and instances grows.

A Clear Path Forward

The architecture of the Hobo SEO Dashboard is fundamentally and deliberately built upon a one-to-one relationship: one dashboard instance is inextricably tied to the identity and authority of one Google Account.

This design choice, rooted in a commitment to maximising data privacy and user control, dictates the necessary strategies for client management. It is not a flaw to be overcome but a principle to be understood and architected around.

For agencies and consultants whose client access can be consolidated under a single Admin Master Account, one dashboard instance provides a powerful, efficient, and highly scalable automated reporting system. This Standard Operating Model represents the tool’s ideal state, leveraging an intelligent, iterative design to deliver immense value without incurring API costs.

However, when client access is fragmented across separate Google accounts that cannot be immediately unified, the only viable and technically sound solution is to implement a parallel-instance architecture. This analysis validates the intuition that multiple dashboards are necessary and provides a robust, expert-level implementation plan to deploy them successfully.

By meticulously following the dual-dashboard strategy – particularly the critical steps of isolating browser environments and creating entirely separate systems for each account – a stable and functional multi-account workflow can be achieved.

While this parallel approach is effective, it introduces operational friction and strategic limitations that should not be ignored.

Therefore, the strategic long-term goal for any user of this tool should remain the consolidation of all client permissions into a single Admin Master Account. This path eliminates management overhead, breaks down data silos, and ultimately unlocks the full efficiency, analytical power, and streamlined management potential of the Hobo SEO Dashboard.

Disclosure: Hobo Web uses generative AI when specifically writing about our own experiences, ideas, stories, concepts, tools, tool documentation or research. Our tool of choice for this process is Google Gemini Pro 2.5 Deep Research and Google Notebooklm. This assistance helps ensure our customers have clarity on everything we are involved with and what we stand for. It also ensures that when customers use Google Search to ask a question about Hobo Web software, the answer is always available to them, and it is as accurate and up-to-date as possible. All content was verified as correct. See our AI policy.