MineArchiveFewer stubs, better records: making MineArchive feel more lived in
3 November 2026
MineArchive has grown very quickly.
That has always been part of the point. There is an enormous amount of British mining history scattered across reports, maps, local history sites, archives and specialist sources, and modern tooling makes it possible to research, organise and publish that material far more quickly than would once have been practical.
There is, however, a difference between being able to build a large structured archive and making sure every public page deserves to exist in its own right.
Over the last few weeks I have been spending quite a bit of time on that distinction.
What changed
A nudge from Google
MineArchive recently applied to Google AdSense and was rejected under its fairly broad "low-value content" classification.
I don't particularly agree with that description of the archive as a whole.
Every mine record published here is checked against the rules established for the project. Records are reviewed before publication, claims are sourced, uncertainty is retained where appropriate, and nothing is deliberately put online that I would not be prepared to stand behind.
When readers have spotted errors or supplied better information, the archive has been corrected.
Records are not considered permanently finished either. Older entries periodically come back through the research process so that sources can be checked again, new material can be incorporated, and the record can be improved where better information has become available.
Nevertheless, Google's rejection prompted a useful question:
Could parts of the site look lower-value than the archive really is?
I think the answer was yes.
In trying to build MineArchive quickly and consistently, I suspect we have run into a few perfectly ordinary teething problems which large, highly structured sites are particularly prone to.
Some pages existed because the underlying data model said that an entity existed, rather than because there was enough information to justify giving that entity an entire public page.
That is now changing.
Operators are relationships, not articles
The clearest example was mine operators.
MineArchive knows about thousands of companies and organisations associated with mines, and originally those operators were given pages of their own.
For some major companies there is plenty that could eventually be written.
For many others, however, the result was effectively a company name, a short paragraph and one or two linked mines.
Technically correct. Structurally useful.
Not necessarily worth asking somebody to open a separate page for.
Those standalone operator pages have now been removed.
The information itself has not gone anywhere. Operators remain important relationships within the archive, but they now work primarily as a way of filtering and exploring the mines themselves.
Clicking an operator can take you to the mine catalogue showing the workings associated with that company rather than to a thin page whose main purpose was to tell you that the relationship existed.
That is both cleaner and, I think, considerably more useful.
Disaster records now have to earn a page too
The same principle is being applied to mining disasters.
There are a great many recorded accidents and incidents in British mining history, but not every one has enough surviving information to support a useful standalone article.
MineArchive is therefore applying a 150-word minimum floor to individual disaster records.
If enough reliable information can be found to give the event proper context, it can stand as a disaster record in its own right.
If there is only a very short surviving account, the information is not discarded. It can instead become part of the history of the mine itself.
A brief roof fall involving one worker may be useful information about a mine without necessarily needing another public page containing a paragraph and little else.
Again, the aim is not to hide information.
It is to be more selective about what deserves its own page.
If MineArchive gives something a page of its own, there should be something there worth reading.
Less "Unknown"
Another small change has been to stop enthusiastically announcing everything we do not know.
Structured data naturally contains empty fields, and earlier versions of the archive tended to expose those rather literally.
Operator: Unknown.
Closure date: Unknown.
Depth: Unknown.
That is accurate, but a page full of empty fields also looks exactly like what it is: a database template waiting for values.
Where uncertainty itself matters, MineArchive will continue to say so. If two sources disagree on a closure date, or the position of a shaft is approximate, that is useful information.
But if a field is simply empty, in most cases it now stays out of sight.
Missing data can be omitted. Meaningful uncertainty should be explained.
That distinction makes for cleaner pages and puts the emphasis back on what is actually known.
Putting the mine back on the map
One of the more visible changes is bringing the map directly into mine records.
Where useful coordinates are known, the mine page can now show a small map near the top of the record with the mine itself pinned in place.
The full MineArchive map has become one of the most useful parts of the site, and increasingly it felt odd that the location of a mine was something you had to leave its record to properly appreciate.
A mine is, after all, a place.
So the page should be able to tell you:
This is where it was.
Where a position is approximate, that will continue to be made clear.
The larger map remains the place for proper exploration, but the smaller map gives the individual record some geographical context immediately and provides a natural route into the workings around it.
It also adds a little colour and movement to what would otherwise be a very traditional article page.
A new visual overview
Mine records are also getting a new Overview panel.
This is intended to sit near the top of the page and give the reader the shape of a mine before they get into the detailed history.
Depending on what is actually known, it might show things such as:
- the historical eras during which the mine was worked;
- the types of disasters associated with it;
- the number of recorded deaths;
- known operators;
- commodities;
- cultural references;
- and, eventually, people or modern observations associated with the site.
The intention is not to turn MineArchive into a statistics dashboard.
Quite the opposite.
A custom set of small illustrated assets is being created specifically for the archive. Different historical periods have their own visual treatment, disaster types have their own imagery, recorded deaths use the MineArchive lantern, commodities have their own small illustrations, and Culture categories are getting their own tiny graphics.
The panel itself has its own dark MineArchive background so that it feels more like a small heritage display or archive plaque than another generic row of website cards.
Most importantly, the panel is driven by the history of the mine.
If a mine only has one known era, one commodity and one operator, the Overview can be small.
If another mine has been worked for centuries, has several disasters, multiple commodities and a complicated operational history, its Overview will naturally be richer.
Empty categories are not shown just to make every panel look the same.
That is deliberate.
Letting the history make the pages different
One of the things I have become increasingly conscious of is that uniformity can be useful right up until the point that it starts making everything look manufactured.
MineArchive is a structured archive, so some consistency is unavoidable and useful.
But not every mine deserves to look identical.
A Roman working which survived into later periods should feel different from a short-lived Victorian colliery.
A mine with a major disaster history should feel different from a small obscure quarry.
A mine which appears repeatedly in literature, television or local folklore should be able to reflect that.
The aim is not to randomly decorate pages.
It is to let the history itself create the variation.
Under the bonnet
Yes, tooling is involved
MineArchive uses a lot of automation and modern tooling.
There is no point pretending otherwise.
It would be extremely difficult for one person to research, structure, maintain and periodically revisit an archive of this size using a completely manual workflow.
The tooling allows much of the repetitive work to be accelerated.
That gives me more time to concentrate on questions such as:
Is this page actually useful?
Does this claim have enough evidence behind it?
Should this record exist on its own?
Does the location need a caveat?
Has a reader supplied better information?
Does this paragraph sound dreadful?
And occasionally:
Who on earth named this mine?
The aim is not to automate judgement.
It is to automate enough of the mechanical work that more judgement can be applied elsewhere.
Tell us what you think
Still learning
MineArchive is a young project.
In our pursuit of filling the archive quickly and in a reasonably uniform way, I suspect we have occasionally produced some of the visual and structural signals that automated systems associate with mass-produced or low-quality sites.
That is worth taking seriously.
I still do not believe it accurately describes the archive itself.
The feedback coming in from readers has been one of the strongest reasons for that confidence.
People have used MineArchive for academic work.
Local history organisations have linked to it.
Families of miners have written in with corrections, memories and information that does not always exist in the formal record.
Readers have challenged details and, when they have been right, the archive has changed.
That is how I hoped this project would work.
Every published record is still expected to meet the archive's basic standards. It is researched, checked and reviewed. Sources should be visible. Claims should be defensible. Uncertainty should not be silently turned into fact.
Records are revisited.
Corrections are made.
Pages which no longer justify their structure are changed.
And where something does not deserve an entire page of its own, I am becoming increasingly comfortable saying so.
The AdSense rejection was irritating.
It was also useful.
It forced me to look at the site not just as the person who built the data model, but as somebody arriving at one of these pages for the first time.
That has already resulted in fewer stub pages, cleaner records, better disaster coverage, less empty metadata, maps appearing where they are actually useful, and a visual language which should make individual mines feel more like individual places.
There will be more changes.
Some will work.
Some probably won't.
That is part of building something like this in public.
MineArchive is still learning how to be MineArchive.
And I think it is becoming a better archive because of it.
Every change here is made for readers, and the best way to find out whether it works is to hear from them. If this one helps, gets in the way, or gave you an idea for something better, write to . Short notes are as welcome as long ones.