🏛️

Museum Website and Hosting Audit with a Demo of the New Site

for a museum complex in Moscow: three sites on one core, shown before the contract

In developmentNDA
31 items
in the technical site audit across 11 sections, each pointing to a file or a database record
3 sites
museum, restaurant and games on a shared core of 2,081 lines
0 external
requests from the demo pages: fonts, images and the map are on our own server

The task

The management of a museum complex in Moscow needed to understand the state of the live website, its risks, what to do and in what order, and what the result would look like. The contract is not yet signed, so promises on paper are not enough: the client wants to see and try the outcome in advance.

Further conditions:

  • three businesses under one roof: a museum, a restaurant with banquets and a games department, and each needs a site;
  • foreign tourists matter only to the museum, the restaurant needs two languages and the games department one;
  • the site must open under any access restrictions, with no calls to foreign services;
  • the demo must not reach search results in place of the live site, and it must not be handed over for wholesale copying.

The solution

The work has three parts: an audit, a document package and a demo stand. A demo stand is a working sample of the new site that accepts no requests or personal data and serves only for showing.

What was done:

  • A technical audit of the site from a backup copy: 11 sections, 31 items.
  • An audit of hosting and domain: what is paid for and what actually works.
  • A document package for management: a commercial proposal of 8 sections and 6 stages, six appendices, decisions and open questions, a re-check protocol, and 11 templates and reference sheets.
  • Internal memos and reports: seven DOCX documents, with the same documents in interactive HTML with light and dark themes and in PDF.
  • A demo stand of four pages: an overall review and three areas, museum, restaurant and games.
  • A presentation panel: five ready scenarios, seven looks, eleven fonts, light and dark themes, three languages, twelve switchable modules, an automatic tour and a QR code for a phone.

How it works

Three sites on a shared core

The shared core is code that describes once the grid, header, cards, forms, cookie notice, panel and accessibility. It contains no colours, no fonts and no hall or programme names: the areas differ only in variables and data. The core is 2,081 lines, the banquet area adds 361 and the games area 535. The museum build is older than the core and lives on its own, with the area switcher, the group strip and the fonts moved onto the core.

A presentation panel that needs no explaining

The panel slides in from the right, and on a phone as a sheet from the bottom. Five scenarios assemble a combination of settings in one tap: «Foundation only», «Everything on», «On a phone», «Showcase», and one of its own for each area. A module that is switched off is removed from the accessibility tree entirely instead of being faded with transparency, so you can see how the site looks without it. The «Show in detail» tables explain what a search engine sees, which external loads a page has and where every figure comes from.

A demo you can try without personal data

The museum demo has sessions for today in Moscow time and a three-step ticket purchase with no payment and no personal-data fields. The restaurant shows a menu of eight sections with a table estimate and an «Add to request» button. The games area calculates a booking total for groups of up to 15 people and gives every programme its own link. Names, durations and some prices are taken from the live site unchanged, while session times and seat availability are made up.

Protecting the demo stand from indexing and copying

Indexing is closed by a meta tag, robots.txt and an X-Robots-Tag header, the last of which covers files too. A gate admits no one past its own page without JavaScript and a cookie. A closed list of downloaders and language-model crawlers gets a 403 refusal, request frequency is limited and embedding the page in a foreign frame is forbidden. So a curl request without a browser gets 302 or 403 for the page itself, which is not a fault. It is a barrier, not a lock: a person with developer tools can see the markup. For real closure the configuration includes a ready-made password-protection block.

A Content-Security-Policy without a single external address

Content-Security-Policy (CSP) is a header that lists where the browser may load resources from. Here it is default-src 'self': every foreign address is forbidden. The fonts (24 families, 218 styles under a free licence) and the map snapshot are stored on our own server. In the demo, the Yandex Metrica counter runs in «showcase» mode and only writes events to the panel's log. In live mode the counter stays silent until cookie consent, and session replay is off because it records what is typed into form fields.

A document package for management

The documents are written for people outside IT. The «Before and after» appendix has 12 comparisons without technical terms, the translation-fix register checks the English and Chinese versions against the Russian original across 44 items, and the data register notes 22 remarks on prices, formats and headings. The main documents come in Markdown, HTML and PDF, and the proposal is printed for signature.

Results

  • Management received a technical audit in which each of 31 items points to a file or a database record.
  • The client sees the future site before the contract and decides for themselves which modules are needed.
  • The demo opens on a phone like an ordinary site, checked at the sizes of three iPhones.
  • The demo sends no data outside: there are no personal-data forms or payments, and no external requests from the pages.
  • Shared maintainability: a change to the grid, accessibility or cookie notice is made once for all three sites.
  • The repository has no automated tests, and checking is manual against the acceptance criteria.

Technologies and why

  • HTML, CSS and JavaScript with no build step or frameworks — the demo opens on any web server and pulls in no dependencies.
  • nginx — serving static files, the gate, security headers, the CSP policy and request rate limiting.
  • Docker and docker-compose — starting the stand with one command on the studio's web server, in its own container and network.
  • Let's Encrypt — HTTPS on the entry nginx that holds ports 80 and 443.
  • Markdown, HTML, PDF, DOCX — the document package in formats for print, on-screen showing and internal paperwork.
  • Real-ESRGAN and AVIF — restoring the first-screen frame with a neural network and converting it to a modern format: 136 KB on a large screen and 84 KB on a phone, at twice the resolution of the previous frame.

Status

Demo stand version 3.5.0 of 22 September 2026, work in progress. Since 18 September 2026 the stand has been hosted on the studio's web server in Moscow and closed to search engines. The document package was prepared and re-checked in early September. Open: the client's decision on the commercial proposal, since the repository holds no status marks for the work. A live chatbot on a language model is not part of the demo: its answers are prerecorded, and a live bot is estimated separately. Other client details are not disclosed.

Questions about this project

How do you show a client the result of a new website before work begins?
You build a demonstration stand where the look, font, language and theme can be changed and twelve modules switched on and off. That shows what each item of the proposal delivers and how the site looks without it. The stand accepts no requests, payments or personal data, and it is shown separately from the live site.
Can one site serve a museum, a restaurant and a games department?
In this project they are three sites on a shared core. The grid, header, forms, cookie notice and accessibility are written once, and everything that differs between the areas is moved into variables and data for each one. A fix to the core applies to all sites at once, so maintenance costs less than three separate copies.
How do you close a demo site to indexing and automatic copying?
Indexing is closed on three levels: a meta tag, robots.txt and an X-Robots-Tag header that also covers images, video and fonts. In addition there is a gate that admits no one without JavaScript and a cookie, a refusal for known site downloaders and language-model crawlers, and request rate limiting. It is a barrier, not a safe: a person with developer tools can see the markup.
How do you build a site that makes no requests to foreign servers?
Fonts, images, video and a map snapshot are stored in the repository and served from the same server. A Content-Security-Policy with default-src 'self' forbids the browser any external address. The «External loads» button in the presentation panel counts requests right in the viewer's browser.
What does the audit of a museum's site and hosting include?
A technical audit of 11 sections and 31 items, each pointing to a file or a database record. A translation-fix register of 44 items, a register of data remarks of 22 items and 12 «now and after» comparisons written without technical terms. Hosting and domain were checked separately: what is paid for and what actually works.
How do you present technical findings to people outside IT?
The demo has an automatic tour of 22 steps in plain words: the «now» steps show a real snapshot of the live site and the «after» steps show the live page. The card says where each fact comes from. A separate note explains the Lighthouse scores: what the check is and where the line between «good» and «bad» lies.

Need something similar?

Tell us about the task — we'll show how we solved it and estimate the scope.