Websites

News website: content flow and editing

A news website differs from an ordinary one not in design but in pace. The roles of editor and writer, drafts and scheduling, sections, the archive and load during traffic spikes.

A news website differs from a corporate one not in appearance but in pace. Stories go stale within hours, there are dozens of publications a day, several people work on one text, and traffic can multiply within fifteen minutes. All of this calls for a different design — of both the admin panel and the infrastructure. Here's what exactly changes.

Publishing speed as a system requirement

On a news website, the path from "we have information" to "the story is on the home page" is measured in minutes. If there's even one step on that path that needs a developer or manual work outside the editor, the newsroom will be late.

What determines speed in practice:

  • An editor that doesn't lag. Autosave every few seconds, working on a poor connection, no lost text when a tab is closed by accident. A lost story isn't just text — it's lost time.
  • One-step publishing. A "publish" button without then placing the story manually on the home page and in the section. All lists are assembled automatically.
  • Fast media handling. Uploading a photo that's resized automatically, embedding video by link, captions and credits right in the editor.
  • Templates. Templates for recurring formats — an announcement, a digest, a story update. Some fields are pre-filled.

A separate requirement is the site's speed for the reader. News is opened on a phone, often on a bad connection, and people leave if the page doesn't appear quickly. That means strict limits on page weight, lazy loading of images and caching ready-made pages instead of building each one on request.

Roles: writer, editor, duty editor

A newsroom has more than one role, and system permissions should reflect that. The minimum set:

  1. Writer. Creates stories, edits their own drafts, submits them for review. Can't publish on their own.
  2. Editor. Sees all stories, edits other people's texts, sends them back for revision, publishes. Responsible for the content of a section or area.
  3. Duty editor. Manages the home page: what's at the top, what's in the selection, what gets taken down. A separate role because it's different work — not about text but about priorities.
  4. Administrator. Users, sections, settings. Has nothing to do with the texts.

The key detail: a story must have an explicit state — draft, in review, ready for release, published, withdrawn. The state is visible to everyone involved, and transitions between states are logged with who made them and when. Without this, in a flow of dozens of stories one of two things regularly happens: a text goes out unchecked or, conversely, gets stuck because everyone thought someone else was working on it.

It also helps to separate authorship from the byline: the actual author in the system and the byline under the story don't always match — one person may prepare a story that goes out under the section's name or with two authors.

In a news flow, the most costly thing isn't mistakes in texts but stories where it's unclear who is working on them right now.

Drafts, scheduling and collaboration

Besides breaking news, there are stories prepared in advance: reviews, interviews, announcements for a known date. They need two things.

Scheduled publishing. The story is ready and waiting — it goes out automatically at the set time. This lets the newsroom spread its workload: prepare in the evening what will come out in the morning.

Protection against concurrent editing. When two people work on a text, one person's changes mustn't overwrite the other's. The minimum workable option is a lock with a warning: "this story is currently being edited by so-and-so". Full real-time collaborative editing is more convenient but noticeably more expensive, and usually excessive at the start.

A feature people remember too late is version history. Who changed what in the text, and the ability to restore a previous version. In a newsroom where a story passes through several hands, it's not a luxury but a way to sort out a disputed situation.

Sections, storylines and the archive

Over time a site accumulates thousands of stories, and the structure determines whether anyone finds them.

Sections are the main division; there should be few of them and they should be stable. A section created for a temporary topic turns into a dead area within six months. Better five permanent sections and a flexible tag system than twenty sections, half of them empty.

Storylines link stories about one developing event. A reader who arrives at the latest update sees the background and can follow how events unfolded. For a news site it's a strong retention tool and at the same time a way to give old stories a second life.

The archive needs separate attention. Old stories keep bringing readers from search, and they need careful handling:

  • story URLs are permanent and don't change when the section changes;
  • the publication date is clearly visible, so the reader knows they're looking at last year's news;
  • an outdated story links to the current continuation of the storyline;
  • deleting stories is an exception, not routine; a redirect is set up on deletion.

How all this affects search traffic and what else structured sections give you is covered in our materials on analytics — without it, it's unclear which sections and storylines actually work.

Load during spikes

A news website lives unevenly. An ordinary day brings predictable load, but one story can gather more in an hour than the whole site does in a week. The infrastructure has to withstand exactly that, not the average.

What helps:

  1. Caching ready-made pages. An anonymous reader gets a pre-built page, not the result of database queries. That's the difference between a site that withstands a spike and one that goes down under it.
  2. Serving images through a CDN. Images are most of the traffic, and serving them from the same server as the pages during a spike isn't an option.
  3. Isolating heavy parts. Comments, view counters and personalised blocks mustn't get in the way of serving the article itself. If the counter stops working, the page must still open.
  4. Event-based cache purging. When a story is updated, the cache for those specific pages is purged immediately, not when it expires. Otherwise the newsroom fixes a mistake while readers keep seeing the old text.

A related issue is protection against floods of automated requests that come with growing visibility. Basic rate limits are worth building in upfront.

Updating a published story

A story lives on after publication: details emerge, mistakes get corrected, assessments change. A newsroom must be able to edit what's published without losing readers' trust.

Working rules worth building into the system:

  • Factual corrections are marked. If the meaning changed, an update note with a date and a short explanation appears at the bottom of the story. Typos are fixed silently; facts are not.
  • The update date is shown separately from the publication date. Replacing the publication date with the edit date confuses readers and looks like an attempt to pass old news off as new.
  • A developing story is a new piece, not a rewritten old one. Otherwise links that have already been shared lead to a text about something else.
  • Withdrawing a story is recorded. If a publication turned out to be wrong, there should be an explanation in its place, not an empty page.

What to check before launch

  1. List the newsroom roles and describe what each can do in the system.
  2. Define the story states and who moves a story between them.
  3. Make sure publishing is one step and doesn't need a developer.
  4. Build in scheduled publishing and version history.
  5. Limit the number of sections and decide whether storylines are needed.
  6. Test the site's behaviour under a multiple increase in load, not under average load.
  7. Agree on the rules for editing published stories and reflect them in the interface.
  8. Set up permanent URLs and redirects for the archive.

These decisions are made before development: reworking an editorial process on a live site costs noticeably more than designing it upfront. More about our approach is on the news and media websites page.