{
  "manualOnly": true,
  "providerRequests": 0,
  "locale": "en",
  "group": "cloud-stacking-seo",
  "title": "Cloud-stacking SEO: inspect the architecture and the claims",
  "notice": "This is a manual planning aid, not a live audit, supplier catalog or ranking prediction. Examples are fictional. Nothing is fetched or submitted; downloaded files stay on your device.",
  "diagram": {
    "title": "Hosting and linking are different relationships",
    "caption": "Conceptual example only. The arrows do not represent endorsement, inherited authority or predicted rankings.",
    "relationLabel": "Architecture relationships",
    "nodes": [
      {
        "id": "host",
        "title": "Hosting service",
        "body": "Provides infrastructure for publisher-controlled content."
      },
      {
        "id": "page",
        "title": "Authored resource",
        "body": "A maintained page with its own reader purpose and evidence."
      },
      {
        "id": "target",
        "title": "Destination page",
        "body": "The specific page referenced in context."
      }
    ],
    "relations": [
      {
        "id": "hosting",
        "from": "host",
        "to": "page",
        "label": "hosts"
      },
      {
        "id": "reference",
        "from": "page",
        "to": "target",
        "label": "contains a contextual link to"
      }
    ]
  },
  "columns": [
    "Review question",
    "Fictional architecture observation",
    "Evidence to request",
    "Interpretation boundary"
  ],
  "rows": [
    {
      "id": "hosting",
      "title": "Who hosts the resource?",
      "values": [
        "A cloud service provides the infrastructure.",
        "The actual public URL and the hosting relationship.",
        "Hosting does not prove independent editorial endorsement."
      ]
    },
    {
      "id": "ownership",
      "title": "Who controls the content?",
      "values": [
        "The same publisher authors the hosted resource.",
        "Content ownership and review responsibility.",
        "A self-published page is not automatically an independent recommendation."
      ]
    },
    {
      "id": "link",
      "title": "What does the link do?",
      "values": [
        "The resource points to a relevant destination.",
        "Actual source, destination and surrounding context.",
        "The arrow denotes a reference, not guaranteed authority transfer."
      ]
    },
    {
      "id": "purpose",
      "title": "Why does the page exist?",
      "values": [
        "A resource answers a stated reader question.",
        "Distinct useful content, sources and maintenance plan.",
        "Many uploads or duplicated pages do not establish reader value."
      ]
    },
    {
      "id": "outcome",
      "title": "What result was observed?",
      "values": [
        "Publication is confirmed; other outcomes remain unverified.",
        "Separate indexing, search, referral and business records if available.",
        "Delivery counts and provider-level metrics are not proof of campaign impact."
      ]
    }
  ],
  "example": "Our fictional diagram contains a hosting service, a publisher-controlled equipment resource and a destination page. One relationship means the service hosts the resource; the other means the resource contains a contextual reference. These are architecture labels, not arrows showing inherited authority or guaranteed ranking transfer. The example is not a deployed stack, a list of available placements or a recommendation to replicate pages across providers.",
  "decision": "Evaluate the purpose and substance of the resource. A maintained document that solves a genuine reader task is different from many near-duplicate pages created mainly to manipulate rankings. Google’s spam policies identify link manipulation and scaled content abuse; the relevant question is how the pages and links are used, not merely whether they sit on cloud infrastructure. Ordinary hosting should not be labeled spam solely because it uses a cloud service.",
  "checklist": [
    "Identify the actual pages and who controls them.",
    "Describe hosting and link relationships separately.",
    "Check reader value and search-policy context.",
    "Separate delivered files from measured outcomes."
  ],
  "reviewRecord": "Ask for the actual URLs, ownership, distinct reader value, publication evidence and the basis of any performance claim. Keep delivery observations separate from indexing, rankings, referral visits and sales. If a seller reports a hosting provider’s domain metric, ask how that relates to the specific published page rather than accepting it as a result. Record uncertainty, paid relationships and maintenance responsibility, and do not interpret missing measurements as proven success."
}