News Publishing Software: The Complete Guide

What is news software?

News software is a content management system designed for periodical publishing. A general-purpose CMS treats “content” as a single abstract object: a title, a body, a publication date. News software knows the content is a news story and spreads that knowledge through every layer of the system. A story has a standfirst, a possible splash, a reporter, an editor’s approval, an update history, a source and a person legally responsible for it.

The practical meaning of that difference is this: in a general-purpose system there is no such concept as “put on the front page”; you construct it by inventing a tag or a custom field. In news software the front page is a first-class concept — its ordering, its duration, its image ratio and who may change it are defined inside the system. The same is true of the archive, the date stamp, the masthead and the separation of roles.

Eight structural differences between news software and a general-purpose CMS

The difference is not the length of a feature list; it is whether the data model recognises journalism. It can be gathered under eight headings.

• The concept of time. A general CMS has a single publication date. In news the moment of first publication, the moments of update and sometimes the time of the event each carry meaning; all three must be stored and displayable.
• The concept of priority. On a blog content is chronological. In news there are editorial priorities — splash, lead, second position, category showcase — and they change many times a day.
• Separation of roles. On a blog an author and an administrator are enough. In news the reporter, editor, page secretary, editor-in-chief and responsible editor have different powers, and who published what must leave a trace.
• Volume. A blog produces five hundred posts in five years. A local news site can reach fifty thousand stories in the same period; search, listing and the archive must be designed at that scale.
• The traffic pattern. Blog traffic is flat. News traffic comes in sudden peaks; the system is built for the peak, not the average load.
• Source and attribution. In news, agency feeds, quotations, archive images and reporter-produced material must be tracked separately; copyright liability depends on it.
• Immutability. A blog post is edited freely. It must be possible to prove that a published story was not altered afterwards.
• Legal obligation. A blog has no masthead requirement. For an online news site the masthead, the date stamp and archive retention are regulated by law.

The last item is usually noticed last and costs the most. If you run an online news site in Turkey, the obligations Press Law No. 5187 lays down for periodicals apply to you too, and some of them are items the software itself has to meet. A whole section of this guide is devoted to that subject.

A day in a newsroom, and what the software does at every step

The most honest way to evaluate software is to run a whole day through it rather than read a feature list. The flow below describes an ordinary day at a local news site, with the software’s job written out separately at each step.

Morning: the news conference and assignments

The day starts with deciding what will be written. At this stage good news software offers a task list, or at least a mechanism for assigning drafts: which reporter is following which subject, which story is expected at what time. Without it, coordination slides into messaging apps and leaves no trace; in the evening there is no answer to “who broke this story”.

During the day: entering the story

The reporter enters the story. Here the software’s job is as much to make mistakes harder as to make the work easier: required fields (standfirst, category, image alt text) must not be left empty, images must be resized automatically on upload, and title length should give feedback on how it will appear in search results. The reporter should not have publishing rights; the story should drop to the editor as a draft.

During the day: editorial check and publication

The editor corrects the text, verifies the category, approves the image and publishes. At the moment of publication the system does several jobs at once: the page is generated, the cache is warmed, the sitemap is updated, search engines are notified, the social sharing card is prepared, a push notification is queued if needed and the content is written to the archive.

Afternoon: arranging the front page

The page secretary or the editor-in-chief rearranges the front page. This is repeated dozens of times a day and must be possible with a drag-and-drop interface; having to open the story edit screen for every change costs half an hour a day.

Evening: breaking news

A breaking story goes in. Traffic multiplies tenfold within minutes. The test of that moment is: does the site stay up, how quickly does the story appear in search results, and in how many seconds does the push notification reach the reader? All three are consequences of architecture, not matters of configuration.

Night: reports

As the day closes you should see which story was read how much, where the readers came from and which category worked. That data is the input to the next day’s news conference; waiting for a weekly report is far too late.

Front page management: the centre of editorial control

The front page is a news site’s most valuable space. The top of the home page determines the reader’s first five seconds, and those five seconds determine the click rate and from there the total traffic. How well the software manages that space produces a direct commercial result.

Good front page management provides:

• Drag-and-drop ordering. Rearranging stories on one screen without opening them.
• Image preview. Seeing in advance how the image of a promoted story will be cropped in that slot.
• Scheduled promotion. A story entering the front page at a set time and leaving at a set time.
• Slot-level permissions. Only the editor-in-chief being able to change the splash.
• Undo. Being able to return a wrongly arranged front page to its previous state.
• A/B headline testing. Comparing the performance of two headlines for the same story.

The last item is absent from most systems and its absence is not fatal; but where it exists it makes a measurable difference over time, because it feeds your headline practice with data.

The production flow: from draft to publication

News production is not a one-person job and software should not assume it is. A healthy flow contains at least three stops: draft, check, publication. In small teams the second stop can be skipped, but the system must support it; because when the team grows, changing the flow is easier than changing a habit.

The questions to ask at each stop:

The last row is particularly important. Removing a story from the site should not mean deleting it from the archive; the law requires published content to be retained. Software that does not observe the difference between removal and deletion can turn a well-meaning editor’s mistake into a legal problem.

Role and permission architecture

Permission management is the most underestimated heading in news software and the one that causes the most problems. The reason is simple: in a small team everyone can do everything and that causes no trouble for a while. It becomes suddenly visible when the team passes ten people, or when an intern changes the front page.

At least five roles should be separated in a newsroom:

• Reporter: enters stories, edits their own drafts, cannot publish.
• Editor: edits and publishes stories in their own area; cannot touch the front page.
• Page secretary: manages the front page and showcase layout; does not touch the text.
• Editor-in-chief: full publishing rights; manages categories and role definitions.
• Responsible editor: the final say in removal, correction and reply processes; the bearer of legal responsibility.

Having a counterpart for that last role in the software is not merely a matter of tidiness. Law No. 5187 requires every periodical to have a responsible editor and lists special conditions for that person. Having the responsible editor defined in the system ensures that reply and correction requests reach the right person; the conditions are set out article by article in the setup guide.

The second dimension of permission architecture is traceability. Who changed what and when must be recorded. That is needed not for trust within the team but to be able to show what happened if a story is questioned.

Category, tag and topic architecture

The commonest information architecture mistake on news sites is confusing categories with tags. A category is a hierarchy: every story belongs to exactly one place and that place produces an archive page. A tag is a cross link: the same story can carry several tags and tags multiply over time.

Keeping the number of categories small is almost always right. On a local news site with fifteen categories most of them receive a few stories a year; that is both an empty page for the reader and a weak signal for search engines. Between five and eight categories is the right range for most publications.

There is a third concept, and it is often what separates good news software: the topic or dossier. An earthquake, an election, a court case lasts months and produces dozens of stories. Gathering them on a single topic page lets the reader follow the process and produces a signal of authority on that subject in search. The difference between a tag and a topic is that a topic has its own description, its own chronology and its own cover image.

• Category: Crime, Economy, Sport, Culture — few, permanent, hierarchical.
• Tag: names of people and institutions, place names — many, can be generated automatically.
• Topic/dossier: “2026 Local Elections”, “One Year After the Earthquake” — few, opened by editorial decision, with its own page.

Archive and search: what happens at fifty thousand stories?

A demo installation has twenty stories and every system is fast. The real test begins when the archive grows. A five-year-old local news site easily reaches thirty to fifty thousand stories, and at that scale three things start to break: the second and third pages of category listings, on-site search, and the story list in the admin panel.

The source of the problem is usually the same: listing queries slow down linearly as the archive grows, because the database has to sort all the records each time. The solution has two layers — correct indexing and a pagination strategy. Classic OFFSET-based pagination produces serious cost on deep pages (page 400, say); cursor-based pagination removes that.

On-site search is a separate subject. Search done with a database LIKE query is particularly weak for Turkish: a search for “çocuk” returns nothing if it was typed “cocuk”, it does no stemming and it produces no relevance ranking. A serious news site needs a full-text search infrastructure, and that infrastructure must handle Turkish character normalisation and stemming.

• Turkish-character-insensitive search (“şişli” and “sisli” should return the same result)
• Stemming (a search for “seçim” should also find “seçimler” and “seçimin”)
• Relevance ranking (a match in the title should come before one in the body)
• Date and category filters
• Tolerance of spelling mistakes
• The search results page itself being fast

Media management: images, video and galleries

Images make up most of the page weight on news sites, and image management is where performance and copyright intersect. Good news software automatically produces every uploaded image in several sizes, converts it to a modern format and serves the right size in the right place.

• Automatic resizing. Separate dimensions for the front page, cards, lists and in-story use.
• Modern format. WebP or AVIF generation, with a fallback for older browsers.
• Lazy loading. Images off-screen loaded later.
• Mandatory alt text. For accessibility and for image search.
• Source and copyright fields. Where the image came from must be recorded.
• Focal point selection. So faces are not cut off in cropping.

The copyright field is absent from most systems and is one of the most expensive omissions. If where an image came from is not recorded, producing a defence to a copyright claim years later is almost impossible. The traps in the licence terms of free image sources are covered in a separate guide, and the use of social media photographs in news in this one.

On the video side the critical decision is where it is hosted. Keeping video on your own server is expensive in bandwidth and the player experience stays weak; keeping it on an external platform creates dependence on that platform’s rules. For publications producing video regularly the right answer is usually a separate video infrastructure with transcoding support.

Performance: carrying breaking-news traffic

News site performance is measured by the peak, not the average load. A local news site taking two thousand visitors an hour on an ordinary day can see twenty thousand within ten minutes during a big event. If the system is not built for that moment, it falls over at exactly the most valuable time.

Caching: the single most important decision

News pages are almost entirely static; once a story is published its content changes very rarely. That makes caching extremely effective. In a well-built cache layer, for twenty thousand people reading the same story the application server generates that page once; the remaining requests are served from cache.

Cache layers stack, and each does a different job:

The critical point is the invalidation strategy. When a story is updated, not only that story but the home page, the category page and any topic page listing it must be refreshed too. In systems that do not do this the complaint “I corrected it but the site shows the old version” becomes chronic.

Measurable targets

To make the performance discussion concrete, set targets. Google’s Core Web Vitals are a good starting point, and two of them are particularly demanding on news sites: the largest contentful paint being fast, and the page layout not shifting. The second is usually broken by advertising slots on news sites; giving ad boxes a fixed height largely solves it.

• The front page image appearing: within the first 2.5 seconds
• Cumulative layout shift: below the threshold, by giving ad slots a fixed height
• Server time to first byte: a few hundred milliseconds on cached pages
• Error rate at the breaking-news moment: close to zero

The data layer: why is one database not enough?

At small scale a single database does every job. As scale grows three separate jobs diverge, and doing all three well with the same tool becomes hard:

• Keeping records. Storing data such as stories, users and categories safely and consistently. A relational database is the right tool here.
• Fast access. Serving small, frequently read data such as the front page, sessions and counters from memory. An in-memory store is the right tool here.
• Counting many rows. Reports such as “how many reads did each category get this month” that scan millions of rows. A columnar analytical database is the right tool here.

It is possible to make one relational database do all three, but the third slows the other two: while a heavy report query runs, the site itself slows down. Separating them keeps the report from affecting the site.

The application layer: what does a Node.js-based news system change?

The technology an application is written in does not by itself produce good or bad news software. But the peculiar pattern of news traffic makes some architectures more suitable than others.

Node.js is an environment that runs JavaScript on the server and is known for its event-driven, non-blocking I/O model: it serves a large number of concurrent connections efficiently on a single thread. The breaking-news moment on a news site is exactly that scenario — many readers, short-lived requests, intensive I/O rather than heavy computation.

• Concurrency. A separate process is not opened for each request; connections are managed in the same event loop.
• Real-time publishing. Live blogs, instant front page updates and push notifications are a natural part of the architecture, not a module added later.
• One language. Server and browser speak the same language; the team moves in a single codebase and the development cycle shortens.
• Ecosystem. A mature pool of libraries for image processing, stream handling and search integration.

It is worth being honest here: news software written in PHP can also be fast; PHP 8 with a modern runtime offers considerable performance and the sentence “PHP is slow” is not true today. What is decisive is not the language but the layers around the application: the cache strategy, data separation, the delivery network and the search engine notification regime. The difference between the options is set out in the script versus platform comparison.

Search visibility: on a news site the most expensive loss is delay

On a general website search engine optimisation is work spread over months. On a news site there is another dimension: time. A breaking story indexed fifteen minutes after publication has lost most of its value, because the reader searching for that subject searches in the first half hour and sees the results indexed first. On a news site the most expensive loss is the story being found late.

SEO in news software must therefore be part of the architecture rather than a plugin added later. The headings below list the items the software must meet.

Technical foundations

• Clean, permanent addresses. A story’s address must not change after publication; if it does, the old address must be permanently redirected to the new one.
• Canonical address. Where the same story is reachable under a category, from a tag or through a parameterised address, a single principal address must be declared.
• Sitemap. Generated automatically and updated when a new story is added.
• News sitemap. A separate map containing the last two days’ stories is a separate signal for Google’s news side.
• robots.txt. Closing the admin panel, search result pages and filter parameters to crawling.
• Pagination markers. Keeping deep category pages crawlable.
• Mobile compatibility. Google indexes mobile-first; a theme that looks good on desktop but breaks on mobile is a direct loss of ranking.

Most of these are set up correctly once and then work by themselves. The question to ask when evaluating software is not “is there SEO support” but “which of these are automatic and which are done by hand”. Every item done by hand is eventually skipped in the daily publishing rhythm.

Title and description

On news sites the page title does two different jobs: on the site’s own front page and in search results. The two need not be the same and usually should not be. A front page headline can be short and striking to arouse curiosity; the title in search results needs to contain what is being searched for.

Good news software lets you keep the two separate: an h1 headline and a separate title field for search. Google’s own guidance sets no strict character limit for titles; what matters is that the title describes the page accurately and that the important part comes first. Long titles may be truncated in results, which is a display choice rather than a penalty.

The meta description is not a ranking factor but it affects the click rate. News software should be set up to use the story’s standfirst when the description is left blank; an empty description leads Google to pick a random sentence from the page.

Structured data

Structured data tells the search engine what the page is in machine-readable form. On a news site at least three types are used:

The commonest mistake in structured data is declaring something that is not on the page. Google’s structured data policies prohibit that expressly: the content you mark up must also be visible to the user. Be particularly careful with rating markup — if you do not collect genuine reviews, adding aggregateRating is a policy violation and carries the risk of manual action.

Google News and Discover

A separate application to appear in Google News is no longer required today; Google discovers news content with its own crawler. But defining your publication identity through Publisher Center lets you declare your logo and section structure.

Discover works differently: it rests on the user’s interests rather than on a search. The most decisive technical condition for appearing in Discover is a high-resolution image; stories with small images almost never enter that feed. It therefore matters that the software can produce a wide-format cover image for every story.

• A wide-format, high-resolution cover image on every story
• Author information and publication date clearly visible
• Avoiding clickbait headlines — Discover penalises them directly
• The page opening fast on mobile

Fast indexing: IndexNow and the notification regime

Rather than waiting for the search engine to find a new story, you can tell it. The IndexNow protocol does exactly that: when an address is published or updated, an instant notification is sent to search engines. Engines supporting the protocol put that notification into their crawl queue.

The counterpart on a news site is a direct revenue effect. Reducing the indexing time of a breaking story from half an hour to a few minutes can determine whether that story appears on the first page. Ask what notifications your software sends at the moment of publication:

• An IndexNow notification (to supporting engines)
• Updating the sitemap
• Updating the news sitemap
• Refreshing the RSS feed
• Purging the delivery network cache on the relevant pages

Is AMP still necessary?

AMP is a simplified page format that opens quickly on mobile. It was once a precondition for appearing in Google’s Top Stories carousel; that condition has been removed. Using AMP today provides no ranking advantage.

There are still situations where AMP is meaningful: if your main theme is heavy and you cannot lighten it in the short term, AMP makes a visible speed difference for mobile readers. But the right route is to lighten the main theme rather than use AMP as a patch. If software can produce AMP that is good; it should not be eliminated for being unable to.

Push notifications

Push notification is the most effective channel for reducing dependence on search engines on news sites. Once a reader gives permission, you can deliver breaking news directly to them. Used wrongly, it is also the fastest way to lose readers.

• Timing of the permission request. Asking as soon as someone enters the site lowers the opt-in rate. Ask after the reader has read at least one story.
• A frequency limit. Do not exceed a few notifications a day; do not send notifications outside breaking news.
• Segments. Offer category-based subscription where possible; a sports reader does not want economy alerts.
• Feedback. Measure how many clicks each notification received.
• Easy unsubscribe. When leaving is made difficult, the reader abandons the site entirely.

Social sharing cards

When a story is shared on a social network, the image, title and description that appear are read from the sharing tags on the page. Missing tags mean an empty box or a random image in the share, which directly lowers the click rate.

The software should automatically produce a correctly sized sharing image for every story and, where there is no image, declare a small card rather than a large one. Promising a large card and not supplying an image produces an empty box in the share.

Measurement and traffic reports

The report a newsroom needs differs from what general analytics tools offer. A journalist does not want “session duration” but “how many people read this story and where did they come from”, and wants it now rather than tomorrow.

• Live reader count and the most read stories at that moment
• Per-story reads, source breakdown and average read ratio
• Performance by reporter and category
• The split between search, social, direct and push
• Weekly and monthly comparison

For those reports not to affect site performance they must be produced in a separate analytics store; otherwise the site itself slows down while the month-end report runs.

The legislation: the obligations the software must meet

This is what separates the choice of news software in Turkey from other countries. Law No. 7418 of 13/10/2022 amended sub-paragraph (c) of Article 2 of Press Law No. 5187 and brought online news sites within the definition of a periodical. The consequence is that some obligations that have existed for the print press for years now apply to online news sites too, and several of them are technical items the software has to meet.

The three headings below are the essentials of any news software. Do not buy without seeing all three with your own eyes during the demo.

The masthead — Art. 4(3)

The paragraph added to Article 4 of the Law by Law No. 7418 requires certain information to be kept on online news sites in a way users can reach directly from the home page and under a “contact” heading. Six items are listed:

• The business address at which the activity is carried on
• The trade name
• The email address
• A contact telephone number
• The electronic notification address
• The name and address of the hosting provider

Two details here are often skipped. The first is the electronic notification address: not an ordinary email but a registered address suitable for service. The second is the name and address of the hosting provider: you must state in the masthead who hosts your site, and even if you use your own server that information cannot be left out.

The counterpart on the software side is keeping the masthead as structured fields rather than a free-text page. In free text nobody notices when one item is deleted; kept as fields, the system can show what is missing. The detail is in the masthead template.

The date stamp — Art. 4(4)

The fourth paragraph added to the same article imposes a separate obligation: the date on which a piece of content was first made available and the dates of subsequent updates are stated on the content in a way that does not change on each access.

The words “in a way that does not change on each access” set a technical condition. Many news themes show the date relatively — “3 hours ago”, “yesterday”; that expression changes on every page load and is not enough on its own. A fixed date must be visible. You do not have to remove the relative expression entirely; it can stay as additional information alongside the fixed date.

The second detail is that update dates must be shown too. The software must keep the moment of first publication and the moment of update in separate fields and be able to print both. A system that keeps a single “date” field and overwrites it on update cannot meet this condition.

The two-year archive — Art. 10

The paragraph added to Article 10 of the Law by Law No. 7418 requires this: content published on an online news site is retained with its accuracy and integrity assured for two years, to be delivered to the requesting Chief Public Prosecutor’s Office where necessary. The article goes on to require that, where the judicial authorities notify in writing that a publication is the subject of an investigation or prosecution, the record of that publication is kept until those proceedings conclude.

The critical phrase is “with its accuracy and integrity assured”. Keeping the content somewhere is not enough; you must be able to show that the content was not altered afterwards. In practice that means the archive being read-only and each record carrying an integrity digest.

The questions to ask on the software side:

• Is every published version stored separately, or does only the latest state remain?
• Is the archive record kept without the content being modified? Is an integrity digest produced?
• Does a story removed from the site remain in the archive?
• In what format can the archive be delivered if a request arrives?
• How much disk space does a two-year archive take?

The last question is a budget item and is often skipped. Together with its images, a two-year archive produces a serious storage requirement at a medium-sized local news site.

Reply and correction — Art. 14

The right of reply and correction of a person whose personality rights have been harmed is one of the oldest institutions of press law and applies to online news sites too. Two requirements arise for the software: recording the incoming request, and showing the published correction in connection with the story concerned.

The periods are short and missing them creates separate liability. The periods that start running when a request arrives are covered in the right of reply petition guide.

Data protection and reader data

A news site collects data from its readers: an email address when a comment is written, a name when someone subscribes to a newsletter, cookies during a visit. Each of those is processing of personal data under Law No. 6698 and the software must offer appropriate tools.

• The privacy notice shown on the relevant forms
• A cookie management tool and storage of preferences
• A record of data subject applications
• Comment and subscription data being exportable and deletable
• Access logs kept for a reasonable, limited period

The position of journalistic activity under data protection law is a separate and subtle subject; the scope of the exemption is covered in a separate guide. On the registration side it is worth checking early whether VERBİS registration is required.

Comments and liability

Opening reader comments is valuable for loyalty but has a liability side. The minimum tools the software must offer are: a pre-moderation option, a word filter, a report button, a record of the commenter’s connection details, and a bulk moderation screen.

Whether moderation is compulsory and the limits of the site’s liability for comments are frequently asked; they are covered in detail in liability for comments and the moderation obligation.

Copyright: quotation, images and agency content

By the nature of news production you make use of content produced by others: a quotation from another publication’s story, a social media post, an agency photograph. The software should make that use traceable — the source and licence of every image and the attribution of every quotation must be recorded.

The limits are narrower than supposed. When quotation is permitted, how much text may be used and whether crediting the source replaces permission are each regulated separately; quoting news, how much may be quoted and crediting the source answer those three questions separately.

Official announcements: what software can and cannot solve

The right to publish official announcements is the most stable revenue item for many local publications, which is why the question “is your software BIK compliant” is asked so often. The honest answer has two parts.

What the software can solve is the technical conditions: keeping the content archive properly, the masthead being complete, the site being continuously accessible, news and visitor traffic being measurable. What the software cannot solve is the personnel condition — the minimum editorial roster is a human resources matter and no software can meet it.

The whole set of conditions is covered in the official announcements guide and the division of labour between software and personnel in the BIK compliant software guide. If you want to see all the obligations with their bases in one list, the legal compliance checklist lets you close the items in order.

Security: why are news sites targets?

News sites attract two separate groups of attacker. The first is automated scanners: bots looking for known vulnerabilities with no particular grudge against your site. The second is targeted attackers: those who want to make the site unreachable or alter its content in response to something published. The second group does not target an ordinary corporate site; it targets a news site.

The minimum measures expected on the software and infrastructure side:

• A current runtime. The application and its dependencies updated regularly, with a clear answer to the question of who updates them.
• Two-factor authentication. On panel logins, especially for accounts with publishing rights.
• Least privilege. Each user having only the permissions they need.
• Login attempt limits. Rate limiting against brute force attacks.
• A web application firewall. Stopping common attack patterns before they reach the application.
• DDoS protection. Absorbing volumetric attacks at the delivery network layer.
• Upload validation. Verifying the type and content of files uploaded to the panel.
• Logging. Being able to trace who did what and when.

The item most often skipped in that list is the last. When an incident happens the critical question is not “what happened” but “when and from where”; with no log there is no answer.

Backup and disaster recovery

A backup is a backup because it can be restored, not because it was taken. On news sites the backup question splits into three separate questions, and all three should have a written answer.

The last row is decisive. A backup that has never been tested is the same as no backup; learning at the moment of crisis that it is corrupt is the worst scenario. Ask your provider “when did you last run a restore test?”

How to choose the best news software

The question “which is the best news software” has no absolute answer, because the right answer varies with the scale of the publication, the technical capacity of the team and the revenue model. But a framework can be built that takes the subjectivity out of the choice. Score on the seven axes below and set the weights according to your own priorities.

The last axis is the least asked and the most important. Discussing the separation scenario at the start of a relationship with a provider may feel odd; but knowing in what format you can take your data also determines the health of the relationship. If you cannot export your content in a standard format, you are technically locked in.

Red flags

• The demo is done only with prepared screenshots
• The word “unlimited” is used without a technical explanation
• No live address can be given when a reference site is requested
• Price items cannot be broken down
• Data ownership is not written expressly in the contract
• It is unclear who will install updates
• “SEO tricks” carrying policy risk, such as rating markup, are offered as features

Professional news site software: additional requirements at corporate scale

The needs of a single-city publication and a newsroom working nationally are not the same. At professional scale the following come into play as additional requirements:

• Multi-publication management. Managing more than one site or regional edition from the same panel.
• Agency feed integration. The incoming feed taken automatically, dropping to editorial approval, with the source information preserved.
• Copy editing and language checks. Automatic spell checking and style guide warnings before publication.
• A publishing plan. Weekly and monthly content calendars, dossier planning.
• An advanced permission matrix. Authorisation by category and region.
• API access. Serving content for a mobile app, screen displays and business partners.
• An audit log. Detailed transaction history usable in legal proceedings.
• A staging environment. Testing theme and module changes before they go live.

The last item is the distinguishing mark of professional scale. A publication that experiments on the live site will sooner or later break in front of its readers.

Purchasing models and pricing

News software is sold under three separate models, and to make prices comparable the model has to be clarified first.

• A one-off licence. The software fee is paid once. Hosting, updates and support are usually separate.
• Subscription. Monthly or annual payment; updates and support are included.
• Licence plus hosting package. The software fee once, the operating fee monthly; the server and maintenance stay with the provider.

When comparing offers, fill in the same items on both sides. The table below contains the items most often overlooked:

When those ten items are filled in, it is a common outcome that the offer looking cheapest at first sight turns out more expensive over three years.

Migration: moving an existing site and archive

Most publications do not start from scratch; they have a working site and an archive accumulated over years. Migration is the riskiest stage of a change of software and, badly managed, can lose years of accumulated search value in a week.

A healthy migration contains these steps:

• 1. Inventory. A full list of existing addresses is produced; which page gets which traffic is measured.
• 2. Address mapping. The new counterpart of every old address is determined. For addresses with no counterpart the closest equivalent is chosen.
• 3. Content transfer. Stories, images, categories and author information are transferred; date fields are preserved.
• 4. A staging environment. The new site is built at a temporary address; work continues on the copy while you keep publishing live.
• 5. Joint checking. The front page, categories, search and randomly selected old stories are compared.
• 6. Cutover. The domain is pointed over and old addresses are permanently redirected to the new ones.
• 7. Post-cutover monitoring. Crawl errors and ranking losses are watched daily for the first week.

The type of redirect in step six is critical: using a temporary redirect leads the search engine to keep the old address. A permanent redirect carries the accumulated value to the new address.

Team, training and going live

Even the best software is useless if it is not used. The commonest mistake in going live is squeezing training into a single meeting. Newsrooms work under pressure; most of what is covered in a two-hour session is forgotten the next day.

• Role-based training. Do not teach front page management to a reporter; teach what they need.
• Short and repeated. Short sessions spread over a week rather than one long one.
• A written guide. With screenshots, searchable, specific to your own site.
• An internal expert. One person on the team learning the system deeply reduces dependence on outside support.
• Close support in the first week. Fast answers in the first days of the transition determine whether the habit settles.

Ten common mistakes

• Deciding on the theme. Design changes; the data model does not.
• Testing with demo data. Every system is fast with twenty stories.
• Leaving the legal items for later. Adding them afterwards means touching every story page.
• Category inflation. Most of fifteen categories stay empty.
• Not testing the backup. An untested backup is not a backup.
• Not separating permissions. A panel where everyone can do everything ends in an accident sooner or later.
• Overusing push notifications. It is the fastest way to lose readers.
• Not recording image sources. No defence can be produced against a copyright claim.
• Not discussing the exit scenario. If you cannot take your data, you are locked in.
• Fake rating markup. Short-term clicks, long-term risk of manual action.

Theme and design system

News site design is a different problem from corporate site design. A corporate site has few pages and each can be designed individually. On a news site thousands of pages are produced from the same template; the design therefore has to be a system rather than a page.

A good news theme defines these components consistently:

• A layout family. Several showcase layouts — lead, grid, magazine and list — with a different layout selectable per category.
• Card types. A large lead card, a medium card, a small list row — each with a different image ratio.
• A typographic scale. A fixed scale for headline, standfirst, body and caption; the same hierarchy on every page.
• Ad slots. Fixed height, not shifting the layout, defined separately for mobile.
• A colour system. Category colours, warning and label colours; light and dark theme counterparts.
• A spacing scale. The distance between components derived from a single scale.

On readability, the commonest mistake on news sites is setting body text too small and too wide. For a long story to be read comfortably the line length should be reasonable, the line height generous and the body size not reduced on mobile. These are not aesthetic preferences but decisions that directly affect reading time and therefore the value of the page.

The riskiest aspect of a theme change is that the legal items sit in the theme layer. If the masthead link and the date stamp are embedded in the theme, they can quietly disappear when the theme changes. In sound news site software those two items are printed independently of the theme chosen.

Advertising management and revenue lines

The commercial side of news software is how it manages advertising slots. There are two separate needs here: placing the codes of programmatic advertising networks, and managing directly sold advertising from the panel.

Ad slot management

• Slot-level definition: home page top, in-story, sidebar, mobile sticky.
• Campaign-level upload: start and end date, impression or click target.
• Category targeting: an advertisement shown only in the sport category.
• Impression and click counters: to be able to report to the advertiser.
• Measuring the ad-blocker rate.
• Fallback content: so the slot is not empty when a campaign ends.

The critical point for performance is that ad code must not block page loading. Ad scripts should load asynchronously and slots should be reserved with a fixed height; otherwise the content shifts down when the advertisement arrives and both the reader experience and the Core Web Vitals measurement suffer.

Sponsored content and labelling

Directly sold content — advertorials, sponsored stories, partnerships — is an important revenue line on news sites and there are labelling rules. The reader must understand at first glance that a piece is advertising; concealing that counts as surreptitious advertising and is subject to sanction.

What is expected on the software side is a separate content type for sponsored content, or at least a visible label field. Squeezing the label into a footnote in small type is not enough. The details are covered in advertorial labelling, the penalty for surreptitious advertising and disclosing partnerships.

The mix of revenue lines

A news site dependent on a single revenue line is fragile. A healthy publication runs at least three together:

Newsletters and permission-based communication

The email newsletter is the most durable channel for reducing dependence on search engines and social networks. It is unaffected by algorithm changes and the reader list belongs to you. Serious news sites therefore treat the newsletter as a main channel rather than a secondary feature.

What is expected on the software side:

• A subscription form and double opt-in registration
• Automatic newsletter compilation (the day’s highlights)
• Segments: category-based subscription
• Open and click measurement
• One-click unsubscribe
• The subscriber list being exportable

Do not neglect the legal side. Sending commercial electronic messages is subject to consent and how the consent was obtained must be provable; a way to unsubscribe must be present in every message. Whether consent is required to send a newsletter, and the limits of the exceptions, are covered in a separate guide. The privacy notice obligation for the reader data collected is set out in the reader privacy notice guide.

Live blogs and developing stories

An earthquake, an election night, an important hearing — in those events the reader expects not a single story but a flowing series of updates. The live blog format meets exactly that and is one of the features where news software makes the most difference.

A good live blog provides:

• Time-stamped entries. Every update with its own time, newest at the top.
• Automatic refresh. The reader seeing new entries without reloading the page.
• Permanent links. Each entry having its own address and being shareable.
• A summary block. “What has happened so far” for readers arriving late.
• Multiple editors. More than one person able to post at the same time.
• Turning into an archive. The page becoming a normal story when the event ends.

Technically a live blog requires a continuous connection from server to browser. That is a job an event-driven architecture naturally does well; connections held open by thousands of readers at once have to be managed efficiently. In the traditional request-response model every open connection consumes a resource and scale quickly becomes a problem.

The live blog has a legislative side too: every entry is published content. The date stamp and archive obligations apply to live blog entries as well; the system must archive them one by one.

Mobile apps and the API

Not every news site needs a mobile app. An app is meaningful only once a loyal readership that returns regularly has formed; otherwise it is downloaded, opened once and deleted. But once that audience exists, an app is markedly better than the mobile site in push permission rates and reading frequency.

Once the app decision is made, the real question is: how will content flow into the app? The answer is an API. The news software must be able to serve content externally in structured form. The same API makes other things possible:

• A mobile app and tablet edition
• Screen displays in a building lobby, corporate screens
• Feeding content to business partners
• Distribution to agency clients
• AI and search services reading the content
• Backup and export

The quality of the API matters as much as its existence: is it versioned, is there a rate limit, how is authentication done, which fields does it return? The last question is particularly critical — if the API does not return the body of the story there is no point writing a mobile app.

The API is also an insurance policy for export. Being able to pull your content in a standard format when you want to leave a provider removes technical dependence.

Accessibility

Accessibility is the most neglected heading on news sites, and the neglect has two costs. The first is a direct loss of readers: those using screen readers, with low vision or navigating by keyboard alone cannot use the site. The second is indirect: many of the adjustments made for accessibility are good for search engines too.

• Image alt text. Text describing what each image shows; left empty for decorative images.
• Heading hierarchy. A single first-level heading on the page with ordered sub-headings below it.
• Colour contrast. Sufficient contrast between text and background; light grey on grey is unreadable.
• Keyboard navigation. Menus, search and galleries usable by keyboard, with a visible focus indicator.
• Link text. Text that says where the link goes, not “click here”.
• Video subtitles. Particularly on news videos.
• Form labels. Every field on comment and subscription forms labelled.

The link text item produces the same result for accessibility and for SEO: text describing where a link goes carries information both to a screen reader user and to a search engine. The commonest mistake on news sites is contextless link text such as “click here for more”.

Artificial intelligence: where it helps and where it creates risk

AI tools provide real benefit at some steps of news production and create direct risk at others. Keeping the distinction clear is necessary both editorially and legally.

Where it helps

• Summarising long documents (council minutes, expert reports, tender specifications)
• Headline and standfirst suggestions — the editor makes the final decision
• Tag and category suggestions
• Spelling and language checks
• Semantic search within the archive
• A draft of image alt text
• Transcription: converting audio recordings to text

Where it is risky

• Producing a whole story — the risk of generating unverified information is high
• Fabricating sources and quotations — models can produce sources that do not exist
• Generating figures and dates — they should not be published unverified
• Generating images — misleading when used as a news photograph

Google’s approach to the subject is clear: what matters is not how the content was produced but whom it serves. Priority in search ranking goes to original, useful content produced to help people; content produced at scale to manipulate rankings is contrary to the policies whatever the production method. In other words “we used AI” is not in itself a problem; “we mass-produced without oversight” is.

On the liability side the position is sharper: the publication, not the software, is responsible for what is published. Who is liable for an error in a story written with AI is covered in a separate guide, and whether an AI-generated image may be used in a news report in this one.

Content removal and access blocking requests

A news site publishing for long enough will receive a removal request. Those requests come from different sources — directly from a person, from a lawyer, from a court — and each carries a different legal weight. What is expected on the software side is that the process is traceable.

Set up an operational flow:

• 1. Record. The date of the request, who it came from and which content it concerns are recorded.
• 2. Classification. A court decision, an administrative decision or a personal request?
• 3. Assessment. The accuracy, currency and public interest of the story are reviewed.
• 4. Decision. Removal, update, publishing a correction or refusal.
• 5. Implementation. The decision is applied; even if the content is removed from the site it is preserved in the archive.
• 6. Notification. The outcome is notified to the requester and recorded.

The third step is the most often skipped. Accepting every incoming request automatically erodes your archive over time and creates an expectation that future requests will be accepted too. The consequences of refusing a request and how the processes work are covered in what to do when a removal request arrives and what happens if I refuse. The time within which access-blocking decisions are implemented is set out in this guide.

The critical distinction on the software side is the same one again: removing from the site and deleting from the archive must not be the same thing. Complying with a removal request without breaching the retention obligation is only possible in a system that makes that distinction.

Choosing hosting: as decisive as the software

Even the best news software runs slowly on an inadequate server. The hosting decision is an inseparable part of the software decision and is made among three options.

There are two additional criteria specific to news sites. The first is resistance to sudden load: shared hosting packages have concurrent connection limits, and at the breaking-news moment it is news sites that hit those limits first. The second is data location: which data centre you are hosted in should be written in your contract; a Turkish location is preferred for data that must be kept in Turkey.

Contract and service level

When the technical evaluation is complete the contract remains, and the clauses to look at are clear. They look dull; but when a problem arises they are the only thing you hold.

• Data ownership. Who owns the content, images and reader data? It must say so expressly.
• Export. When you want to leave, in what format, in how long, and is it chargeable?
• Uptime commitment. The annual availability rate and what happens if it is breached?
• Support response time. Separate periods for critical faults and ordinary requests.
• Maintenance windows. When are planned outages, and how far in advance are they announced?
• Backup commitment. Frequency, retention period and restoration time.
• Price increases. How is an increase at renewal determined, is there a ceiling?
• Intellectual property. Who owns bespoke development?
• Subcontractors. Which services are taken from third parties?
• Termination. In what period, on what conditions, what happens to the data?

The first two are the most critical. If it is not in writing that your data is yours and that you can take it in a standard format, then however good the system you choose technically, you are commercially locked in.

Modules specific to local news sites

In local publishing a significant part of the traffic comes not from stories but from service pages. Those pages are searched daily, returned to regularly and face little competition. They are the area national publications ignore and a local publication owns naturally.

The service modules expected of local news site software:

• Duty pharmacies. A daily updated list by district. One of the most stable items in local search.
• Death notices. One of the most read sections of a local publication; it produces both traffic and a social function.
• Weather. By city, visible on the home page.
• An events calendar. Concerts, theatre, festivals; fed by municipal and cultural centre data.
• Transport and road conditions. Bus times, closed roads.
• A tender and official announcement archive. A searchable archive of the announcements you publish.
• Local sports fixtures. The city team’s match calendar and results.
• Emergency numbers and services on duty.

What those modules have in common is that they need regular updating. A manually updated duty pharmacy page is forgotten within a week and starts giving wrong information — which, in terms of trust, is worse than having no page at all. The software should be able to pull that data from automatic sources or at least warn when it has not been updated.

For publications carrying official announcements the announcement archive matters separately: keeping published announcements in searchable form is both a service to readers and a help on inspection. See the official announcements guide.

Video, podcast and multiple formats

News production is no longer only text. The same event can be produced as a text story, a short video, a podcast episode and a social media card. It is better for the software to recognise those formats as separate content types than to squeeze them all into the “story” mould.

• Video story. Its own player, subtitle support, thumbnail selection.
• Short vertical video. A separate ratio for mobile; transfer to social networks.
• Podcast. An episode list, an RSS feed, distribution to listening platforms.
• Gallery. Ordered images, each with a caption and copyright information.
• Infographic. A large image staying readable on mobile.

On the video side the most critical technical decision is hosting and transcoding. Uploaded video must be converted to different resolutions and the appropriate one served according to the reader’s connection speed; serving a single high-resolution file directly leads mobile readers to stop watching.

For podcasts, being able to produce a standard RSS feed is enough; listening platforms take the content from that feed. The software must support per-episode duration, description and cover image fields.

Regional editions and multi-publication

For organisations publishing in more than one province there are two architectural options: setting up a separate site for each province, or creating regional editions within a single site.

In most cases the second option is right: one panel, one archive, but a structure whose home page and front page change by region. The reader sees the front page for their own province according to their location or their choice; shared stories are published in every edition. The counterpart on the software side is categories and the front page having a regional dimension.

The point to watch on the legislative side is this: your type of publication — national, regional or local — is determined by the criterion of where you publish, and your official announcement category depends on it. Opening a regional edition can affect that definition; see the official announcements guide.

Which indicators should you watch?

Measurement in newsrooms is often reduced to a single number: daily visitors. That number is misleading on its own; a single viral story saves the day but does not show the health of the publication. The set of indicators to watch is:

The most neglected of those is the direct traffic share. Search and social traffic depend on algorithms and can change overnight; the reader who arrives directly is your brand itself. The long-term health of a publication is measured by that share growing.

The second dimension of measurement is editorial feedback: whose stories are read, which category is growing, stories published at which hour are read more. That data produces value when it is an input to the daily news conference; data seen in a report at the end of the month is data that arrived too late.

The product roadmap: assessing the software’s future

When choosing news software you look at its state today; but you will work with it for three to five years. It is therefore worth assessing where the product is going. The questions to ask:

• Which features were added in the last year? Are release notes published?
• Is the roadmap shared, or do features arrive as surprises?
• How do customer requests get onto the roadmap?
• How often are updates released and how are they applied?
• Is backward compatibility preserved? Will an update break my theme?
• Are the technologies used current, or are they versions past end of support?

The last item is the indicator of technical debt. Software running on an end-of-life language version or database is racing against time in security terms even if it looks fine today.

When assessing a roadmap, look not at the number of promised features but at whether past promises were kept. Features announced a year ago and still not shipped show how binding that roadmap is.

From setup to the first year: a ninety-day plan

Choosing software does not by itself produce a result; a go-live plan does. The three-month plan below sets out which work a newly established publication, or one moving to a new platform, should do when.

First 30 days: the foundation

• Domain, hosting and software installation are completed.
• The responsible editor is appointed, the declaration is given, the receipt is kept.
• The six masthead items are published and made reachable from the home page.
• The date stamp is verified on every story template.
• The category structure is built — kept between five and eight.
• Roles are defined: the reporter cannot publish, the editor can.
• Backup is set up and a restore test is run once.
• The sitemap, Search Console and search engine notifications are activated.

Days 31–60: the publishing rhythm

• The daily publishing tempo settles; the news conference routine is established.
• The archive retention arrangement is verified; the removal/deletion distinction is tested.
• The newsletter is set up and double opt-in is enabled.
• Push notifications are activated; the frequency limit is set at the outset.
• Service pages (duty pharmacies, death notices, weather) go live.
• The first performance measurement is made; front page image load time is measured.
• Ad slots are defined with fixed heights.

Days 61–90: going deeper

• The first topic/dossier page is opened and existing stories are linked to it.
• An internal linking scheme is established: every story links to at least one related story.
• A dashboard of measurement indicators is built; the direct traffic share starts to be watched.
• The official announcement conditions are assessed; the staffing position is measured.
• A comment policy is written and published on the site.
• The first quarterly content review: which category worked, which should be closed.

The most critical item in that plan is the restore test in the first month. Knowing the backup works from the first month is different from learning it in the third; because learning it in the third usually means a loss has occurred.

Glossary

The terms used in this guide that you will often hear in purchasing conversations:

A closing word: asking the right question

In the news software market most vendors use the same sentences: fast, secure, SEO-friendly, mobile-friendly. Those sentences do not help you decide because they are all unverified promises. What decides is the quality of the question you ask.

The question “which is the best news software” has no answer; but the question “which is right at my scale, with my team, with my revenue model” does, and the framework in this guide produces that answer. The right answer for a corporate publication looking for professional news site software need not be the same as for a local publication setting up its first site — and it is normal that it is not.

Reduce the evaluation to three concrete tests. First: run an ordinary day from start to finish on the demo. Second: see the masthead, the date stamp and the two-year archive with your own eyes. Third: calculate the thirty-six month total cost and see the exit scenario written in the contract. A system that passes those three tests is good enough for you.

KEYDAL news software: what is in the panel?

If you want to see how the criteria described so far are met in a concrete product, this section describes the KEYDAL news management system by example. The aim is not to list features but to show where each heading above lands in the panel. The full user documentation is published openly at keydal.wiki — you can read it before buying.

KEYDAL is not a news script you download and install. The application runs on Node.js, the public site and the panel sit on Kubernetes as separate components, and each site’s data is isolated in its own database. Setup after ordering is automatic: the database, services and content delivery network are prepared for you.

The panel and navigation

The news site panel is entered from a browser; no installation is needed. The session is kept in a secure cookie that cannot be read by the browser’s JavaScript and therefore cannot be stolen through the site. The session stays open for 12 hours by default.

The menu groups the work and is filtered by your permissions — a section you have no rights to does not appear at all. That is the interface counterpart of the role separation described above:

Note two details. First Corporate → Masthead: the masthead is not free text embedded in a theme but a structured record with its own page in the panel — the direct counterpart of the Article 4(3) obligation described above. Second Corporate → Audit: the audit log showing who did what and when.

There is a live connection indicator in the top bar. Because the panel holds an open connection to the server, a change made by another editor can appear without you refreshing the page; that is the concrete editorial benefit of a real-time architecture.

If you manage more than one publication, the panel works on a single active site and you switch sites from the left bar. Your role on each site is shown beside it; the same person can be an owner on one publication and a reporter on another. Managing regional editions or group publications from one panel becomes possible this way.

Login security

• Two-factor authentication. A six-digit code by email or from an authenticator app.
• Recovery code. Logging in with a previously saved code when you cannot reach your device.
• Temporary lock. The account is briefly locked after many failed attempts; brute force attempts stop there.
• Role badge. Which identity and role you are working with is always visible in the top bar.

Content production

Story entry works in two modes, Simple and Detailed. Simple mode lets the reporter enter quickly; detailed mode opens the fields the editor and the SEO owner need. Tagging is done with a chip-based tag builder offering a suggestion list.

In the Content group the Planning page carries the publishing calendar, the Front page page the showcase layout and the Authors page byline management. RSS and Polls are in the same group.

News site SEO tools

The SEO side works in two layers: inside the story editor and site-wide. Inside the editor, when you enter a focus keyword a live SEO score from 0 to 100 appears and checks four groups — focus keyword placement, title and meta lengths, content structure, readability. The thresholds the system treats as ideal are documented:

The search preview shows how your story will look in results for Google, Bing, Yandex and DuckDuckGo separately, applying each engine’s own truncation length. The title counter turns amber at 60 characters and red at 70.

For every story the meta title, meta description, canonical address, robots directive, sharing image and target keywords can be set separately; the system default is used for those left empty. The hide from Google (noindex) switch works with one click. In structured data the system produces NewsArticle markup automatically; if special markup is needed you can write your own JSON-LD.

Site-wide, robots.txt and the sitemaps are produced automatically. There is a separate address for the Google News side:

We said above that a permanent redirect must be set up when addresses change; the counterpart in the panel is the Redirects screen, which supports four types: 301 for a permanent move, 302 and 307 for a temporary one, and 410 for pages permanently removed. When the web layer cannot find a page for an address it looks at the redirect table before returning a 404.

Its complement is the 404 Monitor: addresses readers requested that do not exist are recorded together with how many times they were requested. When you define a redirect for a frequently hit address the record is marked “resolved” automatically. That pair makes visible the “it is in the sitemap but returns 404” problem most often met in audits.

Media and distribution

In the media library images are separated into folders; an alt text and a copyright field are added to each. We said above that “if where an image came from is not recorded, no defence can be produced against a copyright claim”; the copyright field closes exactly that gap.

A content delivery network is set up automatically for every site: media addresses are served over site.keydal.io and come from edge servers geographically close to the reader through Bunny CDN distribution. With the image optimisation module enabled, uploaded images are converted to WebP and size derivatives are produced automatically.

Themes

The appearance is chosen from a theme catalogue; a default theme is always defined and premium themes appear separately in the catalogue. That a theme change does not affect legal items such as the masthead and the date stamp is ensured by keeping those items in the system rather than in the theme layer.

Modules and plan tiers

Features are switched on and off individually from the Corporate → Modules screen. Modules are divided into eight categories: Content & Media, Readers & Engagement, Analytics & Revenue, SEO & Integration, Social Media, Distribution & Publishing, Marketing and Artificial Intelligence. Which modules you can enable depends on your plan tier, and the tiers are inclusive:

Several modules correspond directly to headings covered separately in this guide. SEO index-push notifies Google and Bing instantly of a published story — the job described in the indexing delay section. Revision history keeps a version on every edit and allows reverting. The Subscription module opens paid membership and a paywall. Omni distributes a single story to push, X, Instagram and WhatsApp. The Agency (AA) module brings an agency feed in with category mapping and drops it into automatic or approved publication — what publications using an agency feed are looking for. The Podcast and Flipbook/magazine modules cover the multi-format side.

Switching a module off does not delete the data it produced; it only disables the feature. Turning off revision history does not destroy old versions, it stops new ones being kept. Every module change is written to the audit log with who and when.

Data isolation and infrastructure

In multi-tenant systems the most critical question is data isolation: does your content sit in the same table as another customer’s data? In KEYDAL every site is isolated in its own database; the panel writes, the public site reads and both work on a single source of truth. Connections are managed through a pooling bridge.

Ordering and setup

Setup after ordering is automatic: your site’s database, services and delivery network are prepared, and billing and subscription renewal are synchronised with the order system. When you upgrade your plan, the modules at the higher tier become enableable by themselves.

Different names for the same thing: terminology

In this market the same product goes by at least ten different names, and that makes comparing offers needlessly hard. What one vendor calls a “news CMS” and another a “news site programme” is usually the same thing; sometimes it is an entirely different delivery model. The table below shows what the names you will meet actually mean in practice.

The practical upshot: when taking offers, look not at the name the vendor uses but at three questions — who holds the server, who installs updates, and who owns the data? The answers to those three determine the delivery model with certainty; the naming does not.

Setup and infrastructure are separate items

Another frequently confused point is assuming setup and infrastructure are the same thing. Setting up a news site is a one-off job: getting the software up, opening the categories, choosing the theme, filling in the masthead. News site infrastructure is continuous: the server, the delivery network, backups, updates and monitoring.

When comparing offers, ask whether the two are priced separately. Some providers show setup as free and price the infrastructure expensively; others do the reverse. Comparison is impossible without seeing the total.

News site hosting: should it be bought separately from the software?

If you are buying a script, news site hosting is a separate decision and should be chosen against the sudden-load criterion described above. If you are buying a platform, hosting is usually included in the package; in that case the questions to ask are “included up to what capacity” and “what happens if I exceed it”. If the answers to both are not in writing you will be surprised during the first big story.

News site themes: how much can be changed?

There are three possibilities in the theme decision: choosing a ready theme from a catalogue, customising a ready theme, or commissioning a fully bespoke design. For a publication starting out the right answer is almost always the first; a bespoke design becomes meaningful after the brand has settled and it has been measured which layout works.

The critical question to ask: are the theme changes I make preserved through system updates? If they are not, you have to redo the design work after every update, and that is an invisible cost item.

Is a mobile news app necessary?

If most of your traffic already comes from mobile browsers, a mobile news app is not a necessity. An app is meaningful only after a loyal, returning readership has formed; before that it is downloaded, opened once and deleted. And when you do decide on an app, the real issue is not the design but how content will flow into it — the answer to which is the API layer described above.

Ask for a demo, not a presentation

The single most useful step in the purchasing process is running a day through the demo environment with your own hands. Instead of a slide deck, ask for a trial panel to be opened and do these things yourself: enter a story, publish it with editorial approval, put it on the front page, upload an image and add alt text and copyright information, fill in the masthead, define a redirect for an address, and update the story and see the date stamp change.

Those seven steps test almost all the criteria in this guide in fifteen minutes. If a provider will not open a trial panel, it is worth asking why.

Guides by type of publication

This guide covers news software in general. If your type of publication differs, so do the requirements: a publication with a printed newspaper wants an issue archive, a radio station a programme guide and a podcast archive, a web TV a video-first structure, and a magazine an issue-based content architecture. For publications seeking the official announcement right a separate set of conditions comes into play.

We have prepared a separate guide for each:

• BIK compliant news software — which of the official announcement conditions software solves and which it does not.
• Newspaper software — running a printed newspaper and a news site from the same panel, the e-paper and issue archive.
• Radio software — a radio station’s news site: an uninterrupted player, programme guide, podcast archive.
• Web TV software — a video-first news site, the VOD archive and video SEO.
• Magazine software — issue-based content structure, the digital magazine and the subscription arrangement.

The point common to radio and television organisations is this: the broadcast is subject to Law No. 6112 and the news content you publish on the site to Law No. 5187. The two regimes do not replace one another; they overlap, and the retention periods differ — one year for the broadcast recording, two years for internet content.

Pre-purchase checklist

Take the list below with you to the demo meeting. Mark each item not “present/absent” but “shown/not shown”.

Editorial

• The reporter–editor–publication flow works and the reporter has no publishing rights
• The front page is arranged by drag and drop and can be undone
• Scheduled publication and scheduled promotion exist
• Version history is kept and who changed what is visible
• Removal and deletion are separate from one another
• A topic/dossier page can be opened

Technical

• Measurements for category and search pages on a thirty-thousand-story installation were shared
• The cache layers and the invalidation strategy were explained
• Images are resized automatically and converted to a modern format
• On-site search is Turkish-character-insensitive and does stemming
• Reports do not affect site performance
• A staging environment is provided

Legislation

• The six masthead items are kept as structured fields
• First publication and update dates are kept separately and printed fixed
• Published content is archived with its integrity preserved
• A story removed from the site remains in the archive
• Reply and correction requests can be recorded
• Cookie and privacy notice tools exist

Search engine

• The sitemap and news sitemap are generated automatically
• An IndexNow notification goes out at the moment of publication
• NewsArticle and BreadcrumbList markup is printed
• The sharing card image is generated automatically, and a small card declared where there is none
• Addresses are permanent, and permanent redirects are set up when they change

Commercial

• The ten price items were given separately in writing
• The thirty-six month total cost was calculated
• Data ownership is written expressly in the contract
• The export format and period were specified
• A support response time was committed to
• Live reference site addresses were given

Frequently asked questions

Are news software and a news script the same thing?

No. A script is a file package you download and install on your own server; the server, updates and security are your responsibility. When news software is sold as a platform you get a working system and operation stays with the provider. The distribution of cost and responsibility between the two is covered in a separate comparison.

Can a news site be built with WordPress?

It can, but the default installation does not meet the items peculiar to journalism. Front page management, role separation, the date stamp, archive integrity and the masthead must each be built separately. Solving them with plugins is possible; the price is the burden of checking after every update whether those solutions have broken.

Is permission needed to start a news site?

No permission or licence is needed. But because online news sites count as periodicals, a declaration is given to the Chief Public Prosecutor’s Office where the place of management is located. The process is set out step by step in the setup guide.

Does news software solve SEO on its own?

No. The software builds the technical foundations: clean addresses, a sitemap, structured data, fast indexing notifications and performance. But what determines ranking is the content itself. Good software removes the technical obstacles in front of good journalism; it does not replace it.

Will I fall behind on Google if I do not use AMP?

No. AMP is not a ranking condition and its requirement for Top Stories has been removed. What matters is the page opening fast on mobile; you can achieve that with AMP or with a light theme.

Do I have to keep my archive for two years?

Article 10 of Law No. 5187 requires content published on an online news site to be retained with its accuracy and integrity assured for two years. In addition, if it is notified in writing that a publication is the subject of an investigation or prosecution, that record must be kept until the proceedings conclude.

How large a team is needed?

Technically a publication can be run by one person. But if you want to publish official announcements the minimum roster condition comes into play, and that is a personnel matter rather than a software one. See the minimum roster guide.

Will I lose traffic when migrating my existing site?

If the address mapping is done correctly and permanent redirects are set up, the loss is limited and temporary. When the loss becomes permanent the cause is almost always the same: some old addresses were not mapped, or temporary redirects were used.

Can I use my own design?

In platform solutions that depends on the provider’s theme architecture. The question to ask before buying is: how much can I change the ready theme, can a fully bespoke design be applied, and are those changes preserved through updates?

Does the software provide BIK compliance?

Partly. It meets some of the technical conditions — the archive, the masthead, accessibility, traffic measurement. It does not meet the personnel and continuity conditions. The phrase “100% compliant software” is misleading because it conceals that distinction.

How do you get into Google News?

A separate application is not required today; Google discovers news content with its own crawler. What you need to do is make the story technically crawlable and quickly indexable: a clean address structure, a news sitemap, structured data and notification at the moment of publication. Defining your publication identity, logo and section structure through Publisher Center improves your appearance.

Should I develop the software myself?

Developing news software from scratch is a permanent maintenance commitment: security patches, search engine changes and legislative updates stay your responsibility for the life of the publication. Unless you have a permanent development team able to take that on, customising a ready system to your needs is almost always cheaper and more durable.

Summary

Choosing news software is a business decision more than a software decision. Look at three axes when deciding: how much the editorial flow speeds up the daily work, how well the technical architecture carries peak traffic and a growing archive, and whether the legislative items are inside the system or will be added later.

The way to measure those three axes is not to read a feature list but to run a real day on the demo and see the three legal items — masthead, date stamp, two-year archive — with your own eyes. Compare price over a thirty-six month total, discuss the exit scenario at the outset, and ask for a live reference before buying.