Web Hub: one place for the content of five websites

Why at all

Five domains of one company have to be recognisable as one company, otherwise each builds authority on its own. That is work nobody does by accident: the domains have to list each other in the data and link to each other in the text. The first time we measured it, not one of the sites listed a single sibling domain, and one of them had no inbound link from anywhere in the group.

The second reason is day to day. Every site has a different content format, different languages and a different branch. An article is easily written in Czech and English while the remaining five languages are forgotten, because nothing anywhere points it out.

What it does

• Status and push across sites. One command prints the branch, uncommitted changes and the difference against GitHub for all five repositories. Another commits and pushes only where something actually changed.
• A check on the group's identity. It reads the structured data of every site and reports where the list of sibling domains is not reciprocal and which site in the group nothing links to. A one-sided star, where one site knows all the others and they know nobody, does not join the entity.
• A register of references. One place recording what exists and which sites it is published on. For each reference it prints where a perspective is missing. That is not always a mistake, but it is a decision somebody has to make deliberately.
• The editorial plan against reality. The plan holds only what is still coming. Finished texts are not copied into it; the tool reads them straight from the repositories and only compares the plan against them, so the two cannot drift apart. For every piece it also says in how many of the site's languages it exists.
• A knowledge graph of the content. The texts of all five sites are staged into one folder and a graph is built over them, finding where the same claim is repeated in different words and where sites fail to link to each other.

Scheduled publishing on five different sites

All five sites do the same thing: you set a date on a text, you can deploy any time beforehand, and the text publishes itself. Until that day it is nowhere, not in the listing, not at its own address, not in the sitemap. The implementation differs on each site, so the hub keeps a table of where that gate lives.

Three things it rests on that must not break during edits. The gate has to be a function, not a constant, because a module-level constant is evaluated once per process and the text would not appear after its date until a restart. The gate is in one place per site, which every listing, the sitemap and the feed read from, so no single path can be forgotten. And a missing date means published, so that adding the gate hid nothing that was already out.

What it deliberately is not

It is not a CMS. The content stays in the repositories in whatever format each site chose, and the tool does not write into it. The checks only read and report; they rewrite and delete nothing. It does not deploy either, that is what the hosting panel is for. And it does not translate: it can count how many languages a text exists in, a person still has to write it.

LinkedIn posts are not sent automatically either. The interface for that needs an approved application and a member token, and neither exists here, so the tool only prepares a draft to copy. That is more honest than claiming it publishes.

Technology

PowerShell over a registry in JSON. The registry holds each site's path, repository, branch, development server port, languages and above all where each kind of content lives in it. That makes the five content parsers the only place that knows about the differences between the sites; the rest of the tool works with one uniform shape. A new site means an entry in the registry and one more parser.

The screens below are real command output, not a mock-up.