DEV Community: Știuriuc Sorin-Marian

Auditing a Next.js Salary Calculator After a 4.5x Search Visibility Spike

Știuriuc Sorin-Marian — Wed, 29 Jul 2026 04:59:44 +0000

At the end of June, a Romanian salary calculator I built entered a very different search environment.

Google Search Console showed roughly 4.5 times more impressions and clicks during the next 28-day period:

Period	Clicks	Impressions	CTR	Weighted position
June 1–28, 2026	495	41,281	1.20%	8.94
June 29–July 26, 2026	2,237	184,388	1.21%	7.77

That is a 351.9% increase in clicks and a 346.7% increase in impressions.

It would make a great case study if I could honestly say: “I changed a few tags, Google rewarded the site, and traffic exploded.”

That is not what happened.

The more useful story is how I audited the site after the spike, separated seasonal demand from technical improvements, and decided what not to change while the data was still incomplete.

The project is salariile.ro, a Next.js and TypeScript calculator for Romanian salaries and payroll taxes.

The first clue was the nearly unchanged CTR

Clicks grew by 4.52x. Impressions grew by 4.47x. CTR moved from 1.20% to 1.21%.

That pattern matters.

If the increase had primarily come from dramatically better titles, snippets, or rankings, I would expect a clearer CTR change. Instead, Google showed the site much more often, and clicks increased almost proportionally.

There was a ranking improvement: weighted average position moved from 8.94 to 7.77. That is useful progress, especially around the first results page, but it does not explain a four-and-a-half-fold increase by itself.

The stronger explanation was external demand.

Romania’s statutory minimum gross salary changed from 4,050 lei to 4,325 lei on July 1, 2026. That created a predictable wave of searches around:

the new minimum net salary;
employer costs;
payroll tax calculations;
gross-to-net conversions;
the effective date of the change.

The comparison window starts on June 29, immediately before the change. It therefore captures the search peak around a national fiscal event, while the previous period does not.

SEO improvements may have helped the site capture some of that demand. They did not create the demand.

That distinction changes how I interpret every metric that follows.

What we cannot conclude

This dataset does not prove that a particular deployment caused the increase.

It does not provide a clean experiment, because several variables changed at once:

search demand rose sharply around July 1;
the query mix changed;
Google crawled and reevaluated pages on its own schedule;
some site improvements were deployed during or after the peak;
Search Console data was not fully finalized through the audit date.

When I ran the analysis on July 29, the latest final Search Console date was July 26. Changes made close to that date did not yet have a complete post-deployment observation window.

A responsible conclusion is:

The site gained substantially more visibility during a major seasonal event, while average position improved and CTR remained almost flat.

A less responsible conclusion would be:

Our latest SEO changes increased organic traffic by 352%.

I am waiting for complete seven-, fourteen-, and twenty-eight-day post-change windows before attributing results to specific work.

1. SSR is an indexability requirement, not just an architecture choice

A calculator is naturally interactive, so it is easy to push too much of it into client-side rendering.

That can produce a page whose browser experience looks correct while its initial HTML contains little more than controls, placeholders, or a loading state.

For the important landing pages, I want the server-rendered response to contain:

the page title and primary heading;
an explanation of the calculation;
the current fiscal values;
useful results or examples;
internal links;
canonical and structured-data signals.

JavaScript should enhance the calculator. It should not be responsible for creating the entire indexable document.

The practical test is simple: fetch the production URL and inspect the returned HTML before hydration. If its main subject is not understandable there, the page is not finished from an SEO perspective.

2. Dynamic routes need an indexation policy

Salary calculators can generate almost unlimited combinations. A route such as /calculator/[value] could theoretically create a page for every possible salary.

That does not mean every value deserves an indexable URL.

Thousands of near-identical pages would fragment internal authority, consume crawl attention, and create little unique value. The project therefore uses an allowlist for salary-value landing pages.

A simplified Next.js pattern looks like this:

const indexedSalaryValues = [4050, 4325, 5000, 10000];

export function generateStaticParams() {
  return indexedSalaryValues.map((value) => ({
    value: String(value),
  }));
}

The exact implementation is less important than the rule: a new indexable value must have demonstrated search demand or a distinct fiscal purpose.

Users can still calculate arbitrary salaries interactively. User input simply does not create an unlimited indexable URL inventory.

3. Canonicals should be tested as contracts

Every indexable page emits a self-referencing canonical.

That sounds basic, but canonical regressions often appear during route refactors, metadata abstraction, query-string handling, or trailing-slash changes.

I do not treat “the component contains a canonical declaration” as sufficient. The rendered production output should answer three questions:

Is the canonical present?
Does it resolve to the intended public URL?
Is that URL indexable and successful?

A canonical pointing to a redirect, a different salary variant, or the wrong hostname can quietly undermine an otherwise good page.

4. Rendered tests catch SEO failures that unit tests miss

Calculation tests verify fiscal logic. They do not verify what a crawler receives.

The project also tests rendered routes for SEO-critical output, including:

HTTP status;
title and description;
one meaningful H1;
canonical URL;
indexability;
expected content;
valid JSON-LD;
treatment of unsupported calculator values.

This turns important SEO behavior into a regression boundary.

If a refactor accidentally removes an H1, changes a canonical, or makes a fiscal page render an empty client shell, the test should fail before deployment.

5. JSON-LD is useful only when it describes the visible page

Structured data is not a place to list every schema type that might generate a rich result.

The site uses page-appropriate entities such as WebApplication, Article, FAQPage, BreadcrumbList, WebPage, and Organization.

The rules I follow are:

the markup must parse;
the type must match the page;
claims must agree with visible content;
dates and URLs must be consistent;
FAQ markup must correspond to questions users can actually read.

Schema validation passing is necessary, but it is not evidence that the page deserves stronger rankings.

6. Crawl the live deployment, not only the repository

The production crawl covered all 63 URLs present in the live sitemap.

The result was 63 successful responses out of 63, with:

no missing or mismatched canonicals;
no accidental noindex;
no invalid JSON-LD;
no missing primary headings;
no duplicate titles or descriptions;
no true orphan pages;
no unexpectedly thin pages under the audit threshold.

That is a useful technical baseline. It is not an SEO victory by itself.

A perfectly crawlable page can still rank poorly because its content is less useful, its intent is unclear, its result is unattractive, or competing domains have much stronger authority.

7. Keep Core Web Vitals in the release gate

Markup and crawlability are only part of the audit.

For Core Web Vitals, I monitor:

LCP for delayed hero content, fonts, and render-blocking assets;
INP for calculator interactions and expensive client-side handlers;
CLS for results, notices, and controls that shift after hydration.

Field data and lab data serve different purposes. Lab runs are excellent regression alarms, while field data shows what real users experience at the 75th percentile.

I do not use a green Lighthouse run to explain an organic traffic spike. Likewise, I would not ignore a real-user performance regression just because rankings had not moved yet.

Performance is a product-quality requirement first and a search signal second.

Why the next bottleneck is probably off-page

The audit did not uncover a technical failure large enough to explain the remaining ranking ceiling.

Several high-volume generic queries sit around positions 6–10. The strongest pages already have sound rendering, canonicals, internal linking, structured data, and substantial content.

At that point, repeatedly rewriting healthy pages can create more risk than value.

The larger gap is external authority: relevant websites independently citing the project as a useful source.

The next phase is therefore not mass link building. It is producing assets that deserve references:

transparent calculation methodology;
reusable fiscal tables and datasets;
reproducible examples;
an embeddable calculator or widget;
original analyses that HR, accounting, and employment publications can verify.

The project’s methodology page exists so readers can inspect assumptions and official sources rather than trust an unexplained number.

For developers who want to inspect the implementation, the repository is public on GitHub.

Relevant editorial citations are useful. Purchased links, automated directory submissions, and unrelated guest-post networks are not a durable strategy, especially for salary and tax information.

My post-spike audit checklist

When a search spike appears, I now ask:

Did clicks grow faster than impressions?
Did CTR or average position materially change?
Was there a seasonal, legal, or news event?
Is the latest Search Console data final?
Does the initial HTML contain the page’s real content?
Are dynamic indexable URLs intentionally limited?
Do rendered pages pass canonical, heading, schema, and status tests?
Are Core Web Vitals healthy in field data?
Is the bottleneck still technical, or has authority become the limiting factor?
What observation window is required before making another change?

The hardest SEO decision can be to wait

A large spike creates pressure to optimize everything immediately.

In this case, the better decision is to preserve the strongest pages, document the baseline, and wait for complete post-event data. The homepage remains the owner of the generic calculator intent until the seasonal wave normalizes and there is enough evidence to justify any migration.

The audit confirmed that the technical foundation is healthy.

It also showed why that is not enough.

Search growth came from the intersection of real-world demand, crawlable implementation, useful content, and improving visibility. The next challenge is earning enough trust outside the site to move important queries from the lower half of page one into the positions where people actually click.

The fiscal edge cases Romanian payroll software gets wrong (and how I modeled them in TypeScript)

Știuriuc Sorin-Marian — Thu, 02 Jul 2026 18:24:45 +0000

Three weeks ago I wrote about modeling Romania's salary taxes in TypeScript for salariile.ro. Since then, Romania's minimum wage changed (July 1st: 4,050 → 4,325 lei gross), and I shipped a payslip generator on top of the same fiscal engine: salariile.ro/fluturas-salariu.

Building it forced me to confront edge cases that, as far as I can tell from comparing outputs, even commercial payroll software gets wrong. Here are three of them.

1. The tax-free allowance survives bonuses (up to a ceiling)

Romania gives minimum-wage earners a fixed tax-free slice: 200 lei/month is exempt from all contributions and income tax (OUG 89/2025). The naive implementation:

const facilitate = (functieDeBaza && brut === SALARIU_MINIM) ? 200 : 0;

That was literally my first version. It's wrong. The actual rule: the allowance applies when the base salary equals the minimum wage AND total gross income (excluding meal vouchers) stays under a ceiling — 4,600 lei since July. So minimum wage + a 200 lei bonus = allowance stays. Minimum wage + a 400 lei bonus = allowance gone, on the entire amount.

const salariuDeBaza = input.salariuDeBaza ? parseFloat(input.salariuDeBaza) : brut;
const facilitate =
  (functieDeBaza && salariuDeBaza === SALARIU_MINIM && brut <= PLAFON_FACILITATE)
    ? DEDUCERE_MINIM
    : 0;

The difference is 80–100 lei/month in the employee's pocket. I've seen real payslips where software silently dropped the allowance the moment any bonus appeared.

2. Personal deduction rounding changed in 2023 — some software never noticed

The personal deduction (a progressive tax shield for lower salaries) used to be rounded up to the nearest 10 lei. Since 2023, the Fiscal Code says you apply the exact computed amount, rounded to the leu.

For a 4,425 lei gross salary: 19% × 4,325 = 821.75 → 822 lei. A well-known Romanian calculator still shows 800 for this case — the old rounding, cascading into a wrong income tax.

How do I know mine is right? I validate against ANAF's own D112 declaration validator (DUKIntegrator) — the same software employers' declarations run through. If my numbers diverge from the official validator, my tests fail.

3. There is no such thing as a 168-hour month

Hourly rate = base salary ÷ monthly working hours. The lazy constant is 168 (21 days × 8h). But Romanian months have 19–23 working days once you subtract weekends and legal holidays. July 2026 has 23 → 184 hours → 23.51 lei/hour at minimum wage, not 25.74.

I generate the working-hours calendar from a single source of truth (a map of legal holidays, shared between the public holidays page and the payslip PDF), so overtime pay is computed on the real month, not an average.

export function zileLucratoareLuna(an: number, luna0: number): number {
  const zileInLuna = new Date(Date.UTC(an, luna0 + 1, 0)).getUTCDate();
  let lucratoare = 0;
  for (let d = 1; d <= zileInLuna; d++) {
    const dow = new Date(Date.UTC(an, luna0, d)).getUTCDay();
    const weekend = dow === 0 || dow === 6;
    const sarbatoare = an === 2026 && Boolean(SARBATORI_LEGALE_2026[`${luna0 + 1}-${d}`]);
    if (!weekend && !sarbatoare) lucratoare++;
  }
  return lucratoare;
}

The meta-lesson

Fiscal law is a spec written in prose, full of exceptions that only surface when real people hit them. The only defense I've found: one pure calculation module as the single source of truth, tests pinned to the official validator's output, and treating every divergence from another calculator as a research task — sometimes they're wrong, sometimes I am.

The whole thing is open source: github.com/xsagul/salariile-ro. If you're Romanian and want to check your own payslip against the law, the generator is free, no account: salariile.ro/fluturas-salariu.

If you've built payroll or tax tools for other countries — do you also validate against the government's own software, or is that a Romanian luxury?

Modeling Romania's salary taxes in TypeScript: lessons from building salariile.ro

Știuriuc Sorin-Marian — Fri, 12 Jun 2026 18:36:15 +0000

I spent the last few weeks building salariile.ro, a salary calculator for Romania. It sounds like a weekend project: take the gross salary, subtract three percentages, show the net. It was not. Here is what made it interesting, and what I would tell anyone who needs to model payroll or tax rules in code.

The domain is the hard part

Romanian salary math in 2026 looks simple on paper: 25% pension contribution (CAS), 10% health insurance (CASS), 10% income tax after deductions, plus 2.25% paid by the employer on top (CAM). The complexity hides in the details:

The personal deduction is not a constant. It is a curve that depends on income and the number of dependents, and it phases out completely above a threshold.
Meal vouchers are taxed differently from cash. CASS and income tax apply to their value, but the tax money is withheld from your cash salary while the full nominal value lands on the card. Many calculators get this subtly wrong, and people then wonder why the payslip does not match the estimate.
Sector rules (construction, agriculture) and the minimum wage facility change the formula depending on contract details.
The rules change constantly. The minimum wage changes again on July 1, 2026, and several thresholds are indexed to it.

My main takeaway: encode rules as data, not as ifs. Every fiscal period is a config object with rates, thresholds, deduction tables and links to the legal source. The calculation engine is a pure function from (config, input) to a payslip breakdown. When the July 2026 rules land, that will be a new config entry plus a set of tests, not a refactor.

Test against official examples

The Romanian tax authority publishes norms for Declaration 112 with worked examples. Every rule I implement gets a test case traced back to an official source, and where two sources disagree, a comment links the exact article of law I followed. For a YMYL topic this is the only thing that keeps the project honest.

The web part: boring on purpose

Next.js 16 App Router, React 19, TypeScript, deployed on Vercel. Server Components everywhere, with the calculator as the only real client component. No cookies, no ads, no tracking scripts. For search visibility the unglamorous things mattered most: correct JSON-LD (Person, FAQPage), a sitemap that actually updates, llms.txt for AI crawlers, and pages that each answer one question instead of one page trying to answer everything.

What surprised me

While researching the niche I found that the sites ranking top 3 for "calculator salariu" include one with almost zero backlink authority and another still showing rules that expired in 2024. In this niche, search engines seem to reward being current and precise more than raw link mass. Encouraging, if you are building something accurate.

The calculator is live at salariile.ro and I am happy to answer questions about modeling tax rules in TypeScript. It is a surprisingly fun domain once you accept the chaos.