I added a “report outdated info” button and ended up building an operations layer

Over the last two days, I expected to spend most of my time publishing more content.

Instead, I ended up building the operational layer required to keep the existing content trustworthy.

I run a multilingual game-information site with guides, an item database, an interactive map, calculators, and a server-aware activity checklist.

The site contains a lot of version-sensitive information. A value can be correct for one service, wrong after a patch, or technically accurate but misleading when its source and date are missing.

That led to one apparently small feature:

“Report outdated info / submit a correction.”

Building the button was easy.

Building everything that needed to happen after someone clicked it was not.

1. A correction needs context

A message saying “this is wrong” is usually not enough to investigate.

Every report now attaches structured context automatically:

• Content, item, map, or tool

• Stable target identifier

• Current language

• Game service or region

• Data version when available

• The page the visitor was viewing

The visitor chooses an issue type:

• Outdated information

• Incorrect information

• Missing information

• Translation problem

• Broken source link

• Other

They can add a description, an optional HTTPS evidence link, and optional contact details.

This produces a much more useful report than a generic contact form because the user does not need to explain which localized page, item, or map record they were viewing.

2. Public feedback cannot publish directly

I did not want a correction form to become a shortcut from anonymous input to public content.

Reports enter a review queue with a new status. They never modify an article, item, or map record automatically.

The public endpoint also needed boundaries:

• Same-origin requests only

• Strictly validated target types and identifiers

• A bounded request size

• Enumerated issue categories

• HTTPS-only evidence links

• A honeypot field

• Rate limiting using a temporary hashed requester identity

• Private, no-store responses

The important product rule is simple:

Community feedback can start a review, but it cannot turn an unverified claim into a published fact.

3. One correction button created an admin workflow

Once reports existed, I needed somewhere to process them.

The private dashboard now supports the following states:

• New

• Triaged

• Accepted

• Rejected

• Resolved

Reports can be filtered by status and language, searched by target or message, opened alongside the affected page, and closed with an internal resolution note.

I did not add public accounts just to secure one internal dashboard.

Admin access uses an allowlisted email-link flow. The session is stored in a secure host-only cookie, while the admin pages and APIs are excluded from search and public navigation.

This was the point where the project stopped being only a collection of pages.

It now had an editorial workflow.

4. Provenance had to become visible before feedback

A correction feature is less useful if visitors cannot tell what the page currently claims.

Content pages now expose more of their evidence boundary:

• Source type

• Service or regional scope

• Publication and verification dates

• Version-sensitive warnings

• Official facts versus editorial assessment

• Community observations versus confirmed information

The correction form then carries that version and service context into the report.

This changed the relationship between provenance and feedback.

Provenance is no longer only something I show to search engines or store in structured data. It helps a reader explain exactly why a page may be outdated.

A live example is the AION2 Brawler guide, where official class facts, editorial difficulty analysis, version scope, sources, and the correction flow remain separate.

5. I measured decisions instead of every possible click

The site already had one GA4 and dataLayer integration, so I kept that as the single analytics path rather than introducing another tracking SDK.

I added events around decisions that can improve the product:

• Starting and submitting a correction

• Completing or reopening a checklist task

• Changing the selected game service

• Opening a related map from the checklist

• Adding a map point to the checklist

• Marking a map point as found

• Sharing a point, route, or map progress

• Entering or leaving map fullscreen mode

Visitors can still change their analytics preference. The goal is to measure meaningful transitions without duplicating GA initialization or turning every hover into an event.

6. The checklist and map now form a small product loop

The daily checklist has moved into the homepage’s main experience instead of being buried in the tools directory.

It understands different game-service clocks and daily or weekly reset cycles. Completion remains on the current device and is never uploaded as player-account data.

Changing the displayed game service changes future reset calculations without erasing the current checklist progress.

The checklist can open relevant map destinations, while map points can be added back into the checklist.

The map itself also received:

• A clearer entry flow

• Site-level navigation

• Fullscreen mode

• Accessible map and icon labels

• Visible loading and failure states

• Localized share-image descriptions

• Improved mobile panel behavior

The live implementations are the server-aware checklist and interactive map.

7. Operational rules became release tests

Several trust and accessibility requirements now fail the production verification step instead of depending on memory.

The verifier checks for problems such as:

• Duplicate titles or descriptions

• Missing image alternative text

• Malformed or incomplete structured data

• Invalid breadcrumb entities

• Private admin routes appearing in search

• Search and generated tool states missing noindex

• Thin item or map-point pages entering the sitemap

• Retired discovery links remaining in llms.txt

• Canonical and sitemap host disagreement

This is not glamorous work, but it changes mistakes from “something I might notice later” into “something the release should reject.”

What I learned

A content product does not become trustworthy just because every article has sources.

It also needs a correction path, abuse boundaries, a review queue, private editorial access, measurable product decisions, and release checks that prevent the same mistakes from returning.

The correction button was a small interface change.

The system behind it became the operational boundary between publishing information and maintaining it.

For other founders running content-heavy or community-assisted products:

At what point did your project need an editorial workflow instead of simply more pages?