An application for tracking article search visibility
An editorial department needed its own way to follow how articles appeared in search results. An internal application tailored to editors and the SEO department replaced a paid external tool.
Each editor can work with their own articles and related queries. Position histories make it possible to compare changes over time across languages and mobile and desktop devices.
- Who it serves
- Editors and SEO specialists responsible for the visibility of published articles.
Scope of responsibility
Atomic Concept is responsible for developing the inherited frontend, bringing the application to deployment and agreeing API and data formats with the backend team.
Returning to an article
For a publication with many articles, a single search result offers only a momentary view. Editors need to return to their own work, see associated queries and understand whether positions are rising, falling or staying broadly stable.
The goal was to replace a paid service with an internal tool suited to the department’s workflow. The application collects recurring position measurements, mainly from Google, and presents them in the context of an article and an editor’s account.
The value lies in keeping the context of successive measurements comparable, as well as seeing a current position. Separating results by language and device lets the department return to the relevant data when assessing a publication’s visibility.
- Publication context
- Articles and queries are associated with accounts so each editor can focus on their own material.
- Comparable history
- Language and mobile or desktop categories help users compare results within the same context.
History in a comparable context
This structural illustration shows how successive measurements can be compared for the same language and device.
- Article and query
- Identify the material being observed.
- Language and device
- Set the context for comparison.
- Successive measurements
- Allow changes to be followed over time.
A tool for editorial work
The work began with an existing, unfinished React interface. It included organizing the code, developing the views needed by the editorial department and preparing the application for deployment.
A separate Ruby on Rails backend provided the data. Request and response formats were agreed with the backend team so article, query and history views could use consistent API contracts.
The views were organized around articles and their associated queries. The application was intended to support regular editorial work and help users select topics for further analysis.
- Working with an article
- Editors can move from their publication list to related queries and their history instead of looking across separate tools.
- Following change
- A sequence of measurements makes trends easier to notice and helps editors choose content for further attention.
Interface and data contracts
The priority was to make the inherited interface easier to develop while keeping it aligned with the SEO department’s actual work. Clear structure and agreed data formats supported subsequent changes.
- Strict TypeScript
- Migrating from JavaScript to strict typing helped expose inconsistencies while developing views and handling data.
- Modular structure
- The code was organized around application features, making individual parts easier to locate and extend.
- Agreed API contracts
- DTOs agreed with the backend developers connected the interface to data returned by Rails.
- Updates without a page reload
- The interface fetches data for a particular view or operation through narrowly scoped endpoints. Editors can move between articles and measurement history without reloading the entire page.
Technologies and their use
- Interface
- React and TypeScript with strict checks.
- Integration
- API and DTOs agreed with the Ruby on Rails backend developers.
- Analysis
- Article and query position histories grouped by language and device.