How to Audit a Cloud Stack Without Mistaking Activity for SEO Value

Nina Okonkwo August 9, 2026

Cloud stacking can create an impressive inventory: public documents, hosted pages, maps, presentations, spreadsheets, profiles, and tiered links. Yet asset count is not the same as search value. A stack can be fully built, publicly accessible, and indexed without producing qualified traffic, a useful customer experience, or measurable improvement to the primary website.

The central audit question is not “How complete is the stack?” It is “Why should each asset exist?”

Practitioner reports associate weak cloud-stack implementations with thin content, duplicate assets, purposeless architecture, repetitive linking, unsupported assumptions about inherited authority, weak measurement, and neglected maintenance. However, the available evidence consists primarily of commercially interested SEO publishers rather than controlled independent comparisons. One relevant source addresses 2025 rather than 2026.

This guide therefore treats cloud stacking as a bounded supplementary experiment—not a proven shortcut or a replacement for useful main-site content, internal linking, technical SEO, local visibility, and legitimate link acquisition. It diagnoses implementation quality, measurement, operational exposure, and opportunity cost. It does not establish current search-engine policy, verify the terms of every hosting platform, promise rankings, or declare cloud stacking compliant or noncompliant as a category.

What cloud stacking SEO means—and what is not proven in 2026

Cloud stacking SEO is commonly described as publishing content on cloud-hosted or Web 2.0 properties, interlinking some of those assets, and directing some links toward a primary website. Assets may include hosted pages, documents, PDFs, presentations, spreadsheets, maps, articles, or infographics.

A Google Stack is the narrower variation. It generally combines Google properties such as Google Sites, Drive, Docs, Sheets, and Maps. Broader cloud stacks may use Amazon-hosted properties, Microsoft Azure, OneDrive, WordPress.com, Blogger, or other third-party environments.

These are practitioner-defined categories, not confirmation that every platform currently allows every proposed use. Publication permissions, public-access settings, moderation practices, privacy requirements, and link treatment must be checked against each platform’s current documentation.

There is no agreed architecture. Semantic Mastery favors a handful of individually developed cloud pages, each assigned a topic, service, city, or geographic purpose and linked to relevant core assets. It also says a new cloud page has little meaningful link equity until relevant backlinks point to it. Its effectiveness discussion concerns 2025, not 2026. Semantic Mastery explains this directly strengthened cloud-page model and contrasts it with longer chains.

A competing practitioner model uses multiple layers:

Tier One: assets linking to the primary website.
Tier Two: assets linking to Tier One.
Tier Three: assets intended to support discovery or higher tiers.

Skills Heaven recommends this layered architecture, along with original content, deliberate interlinking, gradual development, and maintenance. Those are commercial practitioner recommendations, not findings from a controlled comparison. Skills Heaven outlines its tiered cloud-stacking model.

The supplied evidence does not establish that three tiers outperform one tier, that individually strengthened pages outperform tiered stacks, or that either model outperforms a few independently useful resources. It also does not establish that cloud stacking causes ranking improvements in 2026.

The most important unsupported assumption is that a new user-created page automatically receives meaningful ranking power from its host. A prominent platform may make publishing or discovery convenient, but that does not prove that every new document inherits the platform’s reputation or transfers exceptional value through its links. The cited publishers assert different versions of authority transfer without independently demonstrating it.

Use the following evidence framework throughout the audit:

Practitioner observation: A commercial publisher reports a recurring mistake or recommends a technique.
Audit synthesis: A practical check follows from maintaining public assets, but is not presented as a search-engine rule.
Measured result: Analytics or business data show what happened to a specific asset or campaign.
Causal conclusion: Evidence establishes that the cloud asset produced the result rather than merely appearing before it.
Policy conclusion: Current first-party documentation establishes whether a particular implementation is permitted or prohibited.

The supplied evidence supports the first two categories and can help design the third. It does not provide controlled causal evidence or a current first-party policy determination.

The cloud-stacking mistake audit: symptoms, consequences, and first fixes

Start with an inventory rather than a redesign. Record every public URL, its owner, platform, purpose, links, access status, and last review date. Then use this diagnostic table to identify immediate problems.

Mistake	Observable symptom	Likely practical consequence	Diagnostic check	Initial corrective action
Thin content	A short or generic page adds nothing beyond a backlink	Little user value and no defensible reason to retain the asset	Ask what a visitor can learn or do without clicking away	Rewrite around a distinct need or unpublish
Duplicated assets	Several documents repeat the same copy, headings, or claims	Duplicated effort and inconsistent updates	Compare passages, titles, and page purposes	Consolidate overlapping pages
Link-only pages	The page’s only meaningful element is a link	Poor user experience and an obviously link-led purpose	Remove the link mentally and reassess the page	Add standalone utility or remove the asset
Excessive asset creation	The inventory grows faster than it can be reviewed	Maintenance burden and weak quality control	Count unowned, unreviewed, or purposeless URLs	Pause expansion and audit the existing set
Unclear topical purpose	An asset targets unrelated services, entities, or places	Confusing relevance and unfocused content	State its purpose in one sentence	Assign one audience and task or consolidate
Poor interlinking	Links form arbitrary loops or send readers to irrelevant pages	Confusing journeys and difficult attribution	Follow every link as a user would	Keep only links that advance the reader
Repeated destination URLs	Almost every asset points to the same sales page	Mechanical linking and poor destination fit	Group outbound links by destination	Distribute links only where context justifies them
Aggressive anchors	The same exact-match phrase appears repeatedly	Awkward prose and an engineered appearance	Export and classify anchor text	Replace or remove repetitive anchors
Irrelevant backlinks	Unrelated pages link into cloud assets	Weak topical fit and questionable campaign value	Review referring pages for audience and subject alignment	Stop acquiring or routing irrelevant links
Rushed rollout	Many related assets share near-identical copy and publication dates	Quality mistakes and unclear testing	Compare publication history and templates	Replace pacing targets with quality gates
Inaccessible assets	URLs require a login, have restricted sharing, or fail to load	Intended users may not reach them	Test every URL in a logged-out browser	Restore intentional public access or retire
Broken links	Links lead to missing or obsolete pages	Frustrated visitors and lost attribution	Test all outbound links	Update or remove broken destinations
Neglected maintenance	Old addresses, offers, staff, or service details remain public	Inconsistent business information	Compare assets with current business records	Correct, consolidate, or unpublish

The cited practitioner sources most clearly support warnings about thin or duplicate content, link-only assets, excessive creation, repetitive destinations, aggressive linking, rushed deployment, and neglected maintenance. Accessibility, ownership, broken-link, privacy, and data-handling checks are broader operational audit measures rather than documented practitioner consensus.

These issues are not equally consequential. An inaccessible or unindexed page may simply represent wasted effort. A collection containing inaccurate business details, uncontrolled accounts, or information that was not intended to be public requires an immediate operational review. Whether a particular pattern also creates a search-policy, platform-policy, contractual, or legal problem cannot be determined from the supplied sources.

There is no evidence-backed threshold at which an asset count, link count, tier count, or rollout speed becomes excessive. “Too much” depends on purpose, quality, operational capacity, and pattern—not a universal numerical formula.

Consider a stack containing ten near-identical cloud documents copied from one service page. The first response should not be to add another tier or acquire more links. Review the documents for consolidation. Perhaps one can become a detailed process guide and another a genuinely local resource. If the remaining eight have no distinct audience or function, unpublishing them is more defensible than lightly paraphrasing each one.

Remediate in this order:

Remove unintentionally public material and correct inaccurate information.
Restore public accessibility where publication remains intentional and appropriate.
Improve user-facing quality and standalone usefulness.
Simplify repetitive or irrelevant linking.
Measure performance only after the implementation is coherent.

Mistake 1: publishing thin, duplicate, or link-only assets

Thinness is not merely low word count. A 1,000-word page can still be thin if it repeats a sales page, relies on generic filler, or exists only to carry a backlink. A concise checklist can be useful if it solves a defined problem.

All three topical practitioner sources warn in some form against thin, duplicated, or low-value assets. One commercial guide suggests a minimum of 300 to 500 words per asset, but the evidence does not show that crossing this threshold creates quality or improves performance. Word count is an editorial constraint, not proof of usefulness.

Originality requires more than replacing words with synonyms. Each retained asset should serve a distinct question, audience, service, location, entity, or format. Defensible standalone uses might include:

A carefully maintained local resource with accurate information.
A presentation that explains a complicated process visually.
A public dataset with definitions, dates, and an accountable owner.
A checklist that helps a customer prepare for a service.
A map-supported guide based on genuine geographic information.
A document answering a narrower customer question than the main page covers.

Contrast those assets with a cloned sales page, a city template that changes only the place name, a keyword-swapped document, or a page whose only functional element is a commercial link. The latter group creates publishing activity without creating a reason for anyone to visit, reference, or retain the asset.

Score each page against this rubric:

Criterion	Passing question
Unique purpose	Does this asset perform a job no stronger page already performs?
Factual accuracy	Are names, locations, services, dates, and claims current?
Audience usefulness	Can the intended reader gain value without following the backlink?
Topical fit	Does the subject match the audience, format, and destination?
Clear ownership	Is someone accountable for access, accuracy, and updates?
Readable presentation	Is the asset organized, legible, and usable in its published format?
Contextual links	Do its links explain or advance something relevant to the reader?
Reason to remain public	Would publication still be defensible if the links had no SEO effect?

A failing asset has four possible outcomes:

Rewrite it when a clear, distinct purpose exists.
Consolidate it when several assets serve the same audience and task.
Correct it when identity, location, ownership, or service details are inaccurate.
Unpublish it when no standalone use can be defended.

Do not preserve a weak page merely because it is indexed. Historical existence does not establish current value.

Mistake 2: building an architecture before assigning each asset a purpose

A diagram can make a stack look strategic even when its individual pages are unnecessary. Architecture should follow purpose, not substitute for it.

Before publication—or before retaining an existing collection—create an asset map with these fields:

Field	What to record
Platform	The hosting or publishing service
Owner	The person and organization controlling the account
Public URL	The canonical address of the accessible asset
Intended audience	The specific reader the asset serves
Topic or geographic target	Its single primary subject or genuine location focus
Asset format	Page, document, map, sheet, presentation, PDF, or other format
Destination page	Any primary-site or external page it references
Link rationale	Why that link helps the reader
Status	Draft, public, restricted, redirected, consolidated, or retired
Review date	Last verified date and next operational checkpoint

Every retained asset should have one primary purpose: a service explanation, a city-specific resource, a business identity reference, a map-supported guide, a process overview, or a customer education resource. “Tier Two support” is not sufficient by itself because it describes a position in a diagram, not a benefit to an audience.

The competing practitioner models do not resolve which architecture is best. One recommends lower tiers that support higher tiers. Another favors individually developed pages connected more directly to relevant core resources. Neither model has been proven superior, and the supplied evidence supports no universal tier count.

Complexity has practical costs. Every added tier creates more URLs to maintain, more accounts to track, more passages that can overlap, more links that can break, and more ambiguity about which change influenced an outcome. A long chain can also obscure a weak starting point: pages do not become useful merely because they are arranged neatly.

A small illustrative structure might contain:

One useful process guide that contextually references a relevant informational or service page.
One independently useful local resource that references an accurate location or business-identity page.

Those assets do not need to link to each other unless the connection helps a reader. This is an example, not an optimal blueprint.

Avoid creating links merely to complete every line in a diagram. If an asset is orphaned because nothing relevant should link to it, reassess whether it deserves publication. Consolidating purposeless or overlapping assets is usually more coherent than extending the chain.

Mistake 3: assuming the host domain supplies instant authority

The inherited-authority assumption sounds intuitive: Google, Amazon, Microsoft, and major publishing platforms are prominent, so any page hosted on them must begin with exceptional ranking or link value.

The supplied evidence does not prove that proposition. Some practitioner articles claim that links from well-known cloud platforms carry stronger value or trust. Semantic Mastery, by contrast, says a new cloud page has little meaningful link equity until relevant backlinks point to it. That disagreement undermines any confident claim that authority transfers automatically from a parent platform to every user-created page.

Six stages are commonly conflated:

Public accessibility: A logged-out user can open the URL.
Crawlability: A crawler can request and navigate the content.
Indexation: A search engine has included the URL in an index.
Independently earned references: Other relevant pages choose to cite or link to it.
Ranking visibility: The asset or another page appears for meaningful queries.
Qualified traffic or conversions: Visibility produces valuable visits or actions.

Progress at one stage does not establish progress at the next. An indexed document shows that a search engine knows about the URL at that time. It does not demonstrate inherited authority, transferred ranking power, improvement to another URL, or business value.

Evaluate the individual URL instead:

Is it intentionally public and accessible?
Can it be discovered and indexed?
Does it satisfy a distinct audience need?
Has anyone independently referenced it?
Does it receive relevant impressions or referral visits?
Do those visits engage or convert?
Can observed movement be separated from other SEO work?

Do not claim that Google rewards a link because it appears within Google’s ecosystem. Do not label a Google Site or cloud document authoritative solely because of its host.

Mistake 4: repetitive destinations, aggressive anchors, and irrelevant backlinks

A common footprint sends every cloud asset to the same commercial page using the same exact-match anchor. It may satisfy a spreadsheet requirement, but it rarely resembles a useful editorial reference.

Choose destinations according to reader context:

An informational statement can lead to a detailed supporting resource.
A process explanation can reference the relevant service page when that is the reader’s logical next step.
A location statement can lead to an accurate location or identity resource.
A company-name reference may use the brand or plain URL.
A link that does not help the reader can be removed.

Branded, topical, descriptive, and long-tail anchors can reduce awkward mechanical repetition. Anchor diversity is not a compliance device, however. Replacing ten exact-match anchors with ten superficially varied phrases does not legitimize links created primarily to manipulate rankings.

Aeronox Solutions identifies thin or duplicate content, excessive backlinks, poor interlinking, neglected updates, spam links, and fake networks as concerns. These are the agency’s practitioner warnings; its broader claims about authority and 2026 effectiveness are not backed by controlled evidence in the supplied material. Aeronox Solutions summarizes its implementation concerns and commercial opinion.

A cloud page is not a proven protective buffer. Sending questionable links to an intermediary document does not establish that the primary website is insulated from their effects. The more defensible correction is to stop creating or acquiring irrelevant links rather than rely on an unverified buffer theory.

Before:

Ten assets link to /emergency-plumber.
Every link uses “emergency plumber Chicago.”
Several linking assets discuss unrelated topics.
Template footers repeat the link across every page.

After:

Irrelevant links and purposeless assets are removed.
A preparation checklist links once to the relevant emergency-service explanation.
A genuine local resource links to an accurate location page.
An identity document uses the company name where the reference is useful.
Assets with no reader-facing reason to link do not link.

The supplied evidence provides no validated anchor ratio, safe link count, or link-velocity formula. Use relevance and editorial necessity—not percentages—to make decisions. Remove links that do not help readers, reduce repeated destinations, avoid unnecessary template-level links, and assess the topical fit of links pointing into the cloud assets as carefully as the links pointing out.

Mistake 5: confusing a manufactured footprint with gradual, maintainable publishing

Mass publication can make a campaign appear productive. It can also leave teams with duplicated copy, inaccessible URLs, lost account access, obsolete destinations, and public pages nobody is responsible for maintaining.

The practitioner sources identify simultaneous mass creation, stale properties, and neglected updates as implementation failures. They do not validate a “natural” publishing velocity or establish a safe number of assets per day, week, or month.

Replace pacing formulas with operational gates. Before publishing the next asset, confirm:

It has a defined audience and purpose.
Its content is original in function, not merely wording.
Public visibility is intentional.
The platform suits the format and information.
Account ownership and recovery access are documented.
Every destination is relevant and working.
Measurement is configured before publication.
Current platform rules have been checked separately.

A broader maintenance audit should cover:

Public access and logged-out rendering.
Account ownership and credential continuity.
Current indexing status.
Factual and service accuracy.
Consistent business identity details.
Broken, redirected, or obsolete links.
Outdated offers, dates, statistics, and claims.
Duplicated passages across assets.
Changes to destination-page intent.
Changes to platform publication or moderation rules.
Material that may not have been intended for public release.

There is no universal evidence-backed refresh interval. A time-sensitive price document may need frequent review, while a stable process explanation may change less often. Set the review frequency according to how quickly the information can become wrong and the consequences of leaving an error public.

Imagine an abandoned public document containing an old address and a broken link to a deleted sales page. The immediate audit findings are concrete: the information is inaccurate, the user journey is broken, and ownership controls have failed. Any separate policy, privacy, contractual, or legal implications require verification from current platform documentation or appropriate professional guidance.

Use this remediation decision:

Retain accurate, useful, owned assets.
Improve pages with a valid purpose but weak execution.
Consolidate overlapping resources.
Correct identity inconsistencies and outdated claims.
Unpublish low-value, unintentionally public, abandoned, or indefensible assets.

Some questions cannot be settled by a generic SEO audit. Verify current platform terms, publication and moderation rules, link treatment, data-handling requirements, and access continuity for every service used.

Where cloud stacking may create risk—and where the evidence stops

The practitioner sources associate fake networks, spam links, duplicated content, and pages created mainly to influence rankings with possible penalty or guideline concerns. That supports a cautious review, but not a policy verdict on cloud stacking as a category.

The supplied evidence does not include current first-party search-engine documentation establishing exactly when a cloud implementation qualifies as link spam, scaled-content abuse, doorway abuse, or another named violation. It also does not include the current terms of the named hosting platforms.

Accordingly, this guide cannot establish that cloud stacking is:

Prohibited or approved.
“White hat” or inherently abusive.
Penalty-proof or algorithm-proof.
Permitted on every named platform.
Safe merely because its wording is original.

Instead of treating the following characteristics as automatic violations, use them as triggers for closer review:

Assets with no identifiable audience value.
Copied or keyword-swapped pages created at scale.
Locations, businesses, identities, or properties that cannot be verified.
Repetitive exact-match commercial anchors.
Large volumes of topically irrelevant backlinks.
Intermediary pages promoted as safe buffers for questionable links.
Public documents whose intended publication status is unclear.
Accounts controlled only by former employees or outside vendors.
Assets whose only stated rationale is manufacturing ranking signals.

Keep different review questions separate:

Search-policy review: Does current first-party search documentation address the specific content or linking pattern?
Platform-policy review: Do the host’s current terms and publication rules allow the intended use?
Publication review: Was every document deliberately approved for public access?
Ownership review: Does the business control the account and recovery credentials?
Moderation review: What happens if the platform restricts or removes the asset?
Reputation review: Would the organization be comfortable with the asset appearing in a branded search?
Data review: Does the published file contain information or metadata that should be removed before release?

These are audit questions, not findings that a particular implementation has violated a rule or exposed protected information. Answer them using current first-party documentation, account records, internal publication controls, and qualified advice where necessary.

Original wording does not resolve every concern. A network can contain unique sentences while still lacking an audience purpose or using a visibly engineered linking pattern. “Not duplicated” is a content observation, not proof of compliance.

Pause expansion whenever platform permission, intentional public access, durable ownership, or user value cannot be established.

Measure business impact, then decide whether to fix, test, or skip the stack

A cloud-stack audit is incomplete without a baseline. Before rewriting, consolidating, or removing assets, record:

Publication and modification dates.
Target pages and comparable control pages.
Rankings for relevant queries.
Indexed asset URLs.
Referring domains and relevant source pages.
Referral sessions from each asset.
Organic impressions and click-through rates.
Qualified conversions or leads.
Main-site content, internal-link, technical, and local SEO changes.
Conventional backlinks gained during the same period.
Known campaign or algorithm-related dates.

Use campaign annotations and tracked links where appropriate. The objective is to distinguish visits and conversions originating from cloud assets from broader organic movement. Apply tracking parameters consistently while avoiding unnecessary indexable destination variants.

Rankings alone are insufficient. A page may move while the business is refreshing content, earning conventional backlinks, improving internal links, resolving technical problems, or updating local visibility. A before-and-after graph can show sequence, but sequence is not causation.

Keep the outcome categories separate:

Outcome	What it establishes
Indexation	A search engine knows about the URL
Third-party authority score	A tool has assigned a diagnostic score
Ranking correlation	Movement occurred around the same period
Referral traffic	Users arrived through the asset’s link
Qualified lead or conversion	A valuable action followed the visit
Causation	The cloud asset produced the outcome rather than concurrent changes

Causation is the hardest category to establish. A narrower test improves interpretation:

Select a small number of assets with genuine standalone value.
Define target and comparable control pages.
Record the baseline before publication.
Avoid unrelated changes where practical.
Track referral activity and business outcomes.
Set a review window based on operational needs without promising a result date.
Agree on stopping rules before results are known.

Discontinue or simplify assets that remain inaccessible, duplicate stronger pages, provide no standalone value, generate no meaningful engagement, or require disproportionate maintenance. Indexation should not exempt an asset from these rules.

Opportunity cost matters. Semantic Mastery recommends skipping cloud pages when a business already has strong relevant backlinks and local presence. That is a practitioner opinion rather than a universal rule, but it raises the correct question: what higher-confidence work could use the same time and budget?

Alternatives include:

Improving service and product pages on the primary website.
Refreshing useful content that already has visibility.
Strengthening internal links and navigation.
Resolving crawling, rendering, indexing, or performance issues.
Correcting local business information and improving local resources.
Earning relevant editorial links.
Building partnerships and industry relationships.
Pursuing digital PR based on useful research or expertise.

For organizations without the capacity to research, create, publish, and monitor main-site content, an external content service may be more closely aligned with those alternatives. For example, Searcle describes its service as researching buyer demand, creating and publishing content on clients’ existing websites, and monitoring Google and AI-search visibility. This is a first-party description, does not establish performance, and should not be interpreted as evidence of cloud-stacking expertise or as a cloud-stack offering.

Use this decision tree:

Skip the stack when the rationale rests mainly on inherited host authority.
Test narrowly when an asset has genuine user value, reliable ownership, defensible links, and measurable goals.
Remediate when useful assets have fixable access, content, accuracy, or linking errors.
Dismantle when the collection is duplicated, inaccurate, purposeless, unintentionally public, or operationally unmanageable.

Frequently asked questions

Does cloud stacking SEO still work in 2026?

There is no controlled independent evidence in the supplied sources establishing that cloud stacking causes ranking improvements in 2026. Skills Heaven and Aeronox Solutions argue that the tactic may contribute when assets are relevant, logically connected, maintained, and combined with broader optimization, but these are commercial practitioner opinions. Semantic Mastery’s cited effectiveness discussion concerns 2025 rather than 2026.

Treat cloud stacking as a limited supplementary experiment. Require standalone user value, track referral and conversion outcomes, and compare its cost with direct improvements to the primary website.

How many cloud assets or tiers should a stack contain?

There is no evidence-backed optimal number of assets or tiers. One practitioner favors a handful of individually strengthened cloud pages, while another recommends Tier One, Tier Two, and Tier Three layers. No controlled comparison in the supplied evidence establishes which model performs better.

Use the smallest collection that serves clear audience needs. Stop adding assets when new pages duplicate existing material, lack a distinct purpose, complicate maintenance, or exist only to complete a diagram.

Do Google Sites and Google Docs automatically pass more authority because Google owns them?

That should not be assumed. The practitioner sources make conflicting or unsupported claims about parent-platform authority, and none provides a controlled study demonstrating automatic authority transfer to a newly created user page.

Public accessibility, crawlability, and indexation are not proof of authority or link impact. Assess the individual asset’s usefulness, independently earned references, relevant visibility, referral traffic, and conversions.

Should cloud assets link directly to a commercial or money page?

They can reference a commercial page when it is the most useful destination for the reader, but direct linking should not be automatic. An educational asset may be better connected to a detailed guide, while a genuine location resource may appropriately reference a location or identity page.

Avoid sending every asset to one sales URL with the same exact-match anchor. Use fewer contextual links, remove links that do not help readers, and do not rely on anchor variation to legitimize an otherwise engineered pattern.

When should an old cloud asset be updated, consolidated, or removed?

Update an asset when it retains a clear purpose but contains outdated facts, broken links, weak presentation, or incomplete information. Consolidate it when another page serves the same audience and purpose more effectively.

Remove or unpublish it when it has no standalone value, duplicates stronger material, presents inaccurate business information, lacks reliable ownership, was not intentionally made public, or requires more maintenance than its measurable value justifies. There is no universal refresh interval; review frequency should reflect how quickly the information changes and the consequences of leaving an error public.

The final audit decision

Retain a cloud asset only when it has a clear audience, standalone utility, accurate information, defensible links, reliable ownership, and measurable value. Improve or consolidate assets with a valid purpose. Remove those that exist only to manufacture signals, and never interpret indexation alone as success.

In 2026, the supplied evidence supports an audit-and-test approach—not confidence that cloud stacking transfers authority or improves rankings. When direct improvements to the primary website, internal linking, local visibility, content quality, partnerships, or legitimate editorial links offer clearer value, prioritize those investments instead.