Real Estate Platform: zamki-szkocji.com

#zamki-szkocji.com, your guide to Scotland’s magical castles

Most of what decides whether a reference site like this one is still usable ten years after launch is settled in week one, in decisions nobody outside the project ever sees. zamki-szkocji.com went live in 2012 as an information portal about the castles of Scotland: long historical articles, an interactive map, photo and video galleries, and practical notes for people planning a trip. It still carries that shape, which is the interesting part of the story.

The stack is WordPress with Redis for object caching and AWS infrastructure with a CDN in front of the media. Delivery ran about six weeks. The layout and the placement of elements came from the client; my side of the work was turning that layout into a content model, a set of templates and a few integrations that would keep working while the archive kept growing.

#Two audiences that look identical in the analytics

A castle portal serves two different readers who are hard to tell apart from traffic data. One is reading for pleasure and wants a long, well told piece about a place they may never visit. The other is holding a half planned itinerary and wants to know where the castle is, whether it opens in March, and how it fits between two other stops. The first reader needs prose. The second needs data.

Serving only the first produces a pleasant site nobody returns to. Serving only the second produces a directory with no reason to be read. The architecture had to hold both, which is why the central object of the system is not an article at all.

#Main features and technical solutions

Each castle is a record with its own fields rather than a blog post: coordinates, access notes, historical period, architectural style, region, gallery, video material, and a timeline of events tied to the building. In WordPress terms this is a custom post type with its own taxonomies, and the difference it makes only becomes visible at scale.

With twenty objects, ordinary tags work and any alternative looks like over engineering. With several hundred, tags stop being a classification and turn into a pile of near synonyms. Some entries say Highlands, some say north, a few say both, and nobody can tell which list is complete any more. A closed taxonomy forces the decision at the moment of entry, while the editor still has the source in front of them.

The cost is rigidity. A fixed vocabulary has to be thought through up front, and changing it later is a data migration rather than an edit. That trade was easy here, because the geography of Scotland and the classification of defensive architecture do not move from year to year. For a site about events or offers, where the vocabulary shifts with the market, the same choice would be a mistake.

The timeline deserves a note of its own. It is tempting to paste it into the body as ready made markup, which looks right on day one and is useless everywhere else. Stored as dates and events it can be rendered in more than one layout, sorted, and corrected in a single place on the day somebody notices that two sources disagree about when a wing was rebuilt.

The interactive map uses the Google Maps API together with custom endpoints that return location data in a form suited to drawing markers. That separation is the point. If the map asked for full posts, every load would drag the entire historical text across the wire in order to render a pin and a three sentence bubble. A dedicated endpoint returns only what the map draws, so the response is small, caches well, and does not change every time somebody fixes a sentence in an article.

Maintenance benefits too. Location data passes through one place, so rules such as not showing an object without coordinates, or not putting a ruin on the map without access notes, live in code instead of in an editor’s habits. On a site that grows for a decade, that is the difference between a map that reflects the database and a map somebody has to audit by hand once a year.

Galleries and media switching run through AJAX, so moving between photographs does not reload the page. The benefit is obvious; the cost less so. Content that only exists after a script runs does not exist for every visitor: a crawler in the bad case, a screen reader in the worse one. So the address of a single image and the description of the object have to be present in ordinary HTML, with AJAX as an acceleration of navigation rather than the only way in.

Comments and ratings let visitors add their own experience of a place. It is a feature that is easy to launch and expensive to keep, because any open form on a site with search visibility is found by automated traffic within weeks. The practical lesson from this build is to moderate strictly and relax later, rather than clean up months of accumulated link spam sitting under a description of a fifteenth century keep.

#Challenges and implemented programming solutions

Performance was the real constraint, and it could not be solved by making the site lighter. The photographs are the content. Removing them would have solved the measurement by removing the reason anyone visits.

Redis handles object caching. A WordPress page is assembled from many small reads: options, metadata, taxonomy relationships. On an archive view showing dozens of castles with their fields, the number of those reads grows faster than the number of visible elements suggests. Keeping the results outside the database means the next request does not repeat the same work. This matters most exactly where full page caching cannot help: parameterised views, the map endpoint, any request from a logged in editor.

The CDN handles the media. Castle photography is heavy, and the audience is spread between Poland, the British Isles, and wherever somebody is planning a holiday from. Serving those files from a single origin means half the readers wait for a transfer across Europe every time. Pushing them to locations near the reader also takes work off the application server that never belonged there.

Traffic on a travel site is not evenly distributed, which changes what tuning is worth doing. It rises with the season and jumps after a mention in the press or a share in a large interest group. Optimising for the monthly average is close to pointless. What counts is the hour when the site sees many times its usual load, and in that hour the thing that saves you is not faster code but the fact that most responses never reach the application at all.

Cache lifetimes were set deliberately rather than left at a plugin default. A description of a castle can sit in cache for hours, because it changes a few times a year. A notice about a temporary closure cannot, because that is precisely the information somebody came for the evening before a trip. Separating those two cases is cheaper than shortening the global lifetime, which degrades performance everywhere in order to fix one view.

All of this was measured against a copy of production rather than a clean install. That distinction is easy to miss once and never again. An empty WordPress with a theme and two posts answers quickly no matter how the queries are written. Only a database carrying the full set of objects, their metadata, taxonomy relationships and comment history shows which query scans half a table and which one uses an index.

On the search side the work was semantic HTML5, tidy metadata, readable URLs derived from structure rather than identifiers, and schema.org structured data describing the castle articles. The purpose is narrow: describe to a machine what a person reads from the layout. Structured data will not put a weak description above a good one. It stops a good description from being missed because a crawler could not work out what kind of page it was looking at. I do not have measurements of the effect that I could honestly quote here, so I am not quoting any.

#Support and maintenance of the site

Ongoing care covers core, theme and plugin updates, log review, backups, and small functional or visual changes. For a site running since 2012, maintenance is the larger part of the story, and it should be budgeted that way rather than treated as an afterthought once the build is paid for.

Updates are tested on a copy. A site with a custom content type, custom taxonomies and an external map integration has several places where a change in core or in a plugin alters behaviour without raising an error: a query is built differently, a filter one view depended on quietly disappears, the map provider retires an old authentication method.

Backups are a restore procedure, not a file on a disk. A backup nobody has restored from is a statement of intent. The one worth having is the one that has been used to stand up a working copy of the site at least once, with somebody noting how long that took.

#Summary

zamki-szkocji.com holds up because of things invisible from the outside: castles modelled as records rather than articles, map data separated into its own endpoint, object caching kept distinct from media delivery, and content that stays in the HTML document even where AJAX makes navigation faster.

What carries over to the next project is the technical layer and the method: WordPress, Redis, AWS and a CDN, structured data, and testing against a copy of production. What does not carry over is this site’s content model or its integrations, which were written for one body of data and one way of reading it. A new build starts with a scope review, and the quote comes after that review rather than before it.