Domain Age of Flagged Online Stores: A Study of 1,000 Records

The domain-age picture changes sharply depending on which flagged store records you count. In Gridinsoft’s September 12 study, newly added records had a median domain registration age of 100 days; updated records that were already in the database had a median of 544 days. Combining them produced a median of 368 days. Those figures describe records classified as Suspicious Shop—an automated warning category, not a set of independently confirmed fraudulent stores.

We sampled 1,000 current records from a pool of 4,411 saved or updated during the preceding 30 days. Registration dates passed our quality checks for 917 records. This article explains the difference between the two groups, how we checked the dates, and how to reuse the results without turning a database observation into a claim about every online shop.

Key findings from the September 2026 snapshot

• New records: 94 of 366 with usable registration dates—25.7%—had domains registered at least 365 days before the snapshot. Their median age was 100 days.
• Updated older records: 370 of 551 with usable dates—67.2%—met the same age threshold. Their median age was 544 days.
• Date coverage: 917 of the 1,000 sampled records—91.7%—were included in the age calculations. The remaining 83 were excluded from the age calculations for the reasons explained below.
• Registry cross-check: all 35 comparable RDAP registration dates agreed with the saved dates within the predefined one-day tolerance. Five of the 40 planned checks did not return a comparable date.

See the sampling and date-checking method below for the scope and limitations.

In this study: age distribution · effect of the record mix · missing-date sensitivity · classification routes · validation · full methodology.

Why new records and updates tell different stories

“New” here means a record first saved in Gridinsoft’s database during the study window. It does not mean that the domain was newly registered, that the store had just opened, or that harmful activity had just begun. A domain can be years old when it first enters the database.

The second group contains records first saved before the window and saved again within it. There were more of these older-record updates in the sample: 585, compared with 415 newly added records. Mixing the groups gives more weight to the update group and changes the overall age profile.

Among the 415 newly added records, 33 had already been saved again during the same 30-day window. They remain in the new-record group because that grouping uses their first saved date. All domain ages are measured at the fixed September 12 snapshot, not at the time of first detection.

This is why the combined figure needs its denominator and selection rule attached. “50.6% of usable dates in this sample were at least 365 days old” is supported. “Most scam stores are over a year old” is a different claim, which this study did not establish.

How were domain ages distributed?

The six age bands below use complete days since the saved registration date. Each usable record appears in exactly one band. Percentages in the chart use the usable-date count for each group, allowing the two differently sized groups to be compared.

The zero in the youngest band for older updates should not be read as a discovery about scammer behavior. Those records were first saved more than 30 days before the snapshot, and the primary date rules exclude registrations more than a day after a record’s first save. The selection and chronology checks themselves constrain this group.

Where is the gap concentrated?

Among new records with usable dates, 167/366 (45.6%) were younger than 90 days. The corresponding figure for older-record updates was 23/551 (4.2%). The largest band in the update group was 365–1,094 days: 248/551 (45.0%). For new records, the largest band was 30–89 days: 94/366 (25.7%). The medians summarize distributions whose concentrations are in different places.

Both groups also contain substantially older registrations. Domains aged at least 1,095 days accounted for 49/366 (13.4%) of new records and 122/551 (22.1%) of updates. Their presence shows that a newly added database record can concern a long-registered domain. It does not establish how long its current shop has operated.

How much does the mix change the combined result?

The update group supplies 551/917 (60.1%) of usable dates, while new records supply 366/917 (39.9%). The combined share aged at least 365 days is their weighted average: each group’s age share multiplied by its share of usable records. Using the exact counts gives 464/917 (50.6%).

For illustration, an equal mix of usable new records and usable updates would give 46.4% aged at least 365 days. A mix containing 75% updates would give 56.8%. Every 10-percentage-point increase in the update weight adds about 4.15 percentage points to the combined age share, with both within-group percentages held constant.

That is a practical issue for reporting. A future snapshot could have a different combined percentage simply because the balance of new records and updates changed. Before interpreting a difference as a change in the stores being flagged, compare the same record groups, date coverage and selection rules. The line above illustrates this arithmetic sensitivity; this single snapshot cannot establish a time trend.

The calculation applies to a percentage, not to the median. The combined median of 368 days comes from sorting all 917 usable ages; it cannot be obtained by taking a weighted average of the two group medians.

What difference do the 83 excluded dates make?

We excluded 45 records without a positive registration date, 16 carrying an estimated age instead of a registration date, 13 with a missing or mismatched WHOIS name after earlier checks, and nine whose registration date was more than a day later than the first saved record. The last group may reflect re-registration or a data error. Estimated dates from archived pages or profiles were not treated as registry dates.

These are mutually exclusive primary exclusion reasons. Some underlying diagnostic flags overlap; adding every flag together would double-count some records.

If none of the 83 excluded records had a domain age of at least 365 days, the share across all 1,000 selected records would be 46.4%. If all 83 did, it would be 54.7%. These are worst-case bounds for missing dates, not a confidence interval. They cross 50%, so the data do not establish a majority across the entire sample.

A separate sensitivity calculation that admits the nine possible re-registration cases produces 464/926 (50.1%) and a median of 365 days. It does not replace the predefined primary result.

Does missingness change the comparison between groups?

Usable-date coverage was lower for new records than for updates. The table applies the same all-younger versus all-older assumptions within each group. Its final column uses every selected record in that group as the denominator, including records without usable dates.

Even the upper bound for new records (34.5%) is below the lower bound for updates (63.2%). Thus, within the selected sample and assuming the accepted dates are correct, assigning the missing ages in either direction cannot reverse that group difference. This is a narrower and more robust observation than claiming a majority for the combined sample. These bounds address unavailable ages only; they do not correct classification bias or make the sample representative of all online stores.

What does “Suspicious Shop” mean in this study?

It is the category assigned to the stored record at the snapshot. Five saved decision routes were represented: engine report, low external reputation score, a fake-shop risk tag, a carried-forward database category, and external blacklist signals combined with shop context. These are classification routes, not five independent investigations of each site. A route identifies how the saved category was obtained; it does not enumerate every input behind that decision.

How do the age summaries differ by decision route?

The engine-report route accounts for 579 of the 1,000 records. Its usable dates have a median age of 543 days. The low external-score route accounts for 268 records, with a median age of 114 days among usable dates. The complete route summaries are below; each percentage uses that route’s usable-date denominator.

These route-level differences overlap with the difference between new records and updates. Of the 579 engine-report records, 546 (94.3%) were older-record updates. Of the 268 low external-score records, 244 (91.0%) were newly added. Comparing their overall medians therefore compares different record histories as well as different decision routes.

The engine-report route makes that issue concrete: its new-record subset has a median of 151 days across just 19 usable dates, while its update subset has a median of 558.5 days across 512 usable dates. Only 19 of the 33 new engine-report records have usable dates, so that small subset also has weaker coverage. The overall 543-day median mostly describes updates. The half-day in the 512-record median is the average of the two middle whole-day ages, not a more precise timestamp measurement.

For the carried-forward category, the original decision basis was not reconstructed. An engine-report route also does not establish that every input was independent of outside reputation systems. These details prevent a route label from being interpreted as proof of a particular verification standard.

Domain age already contributes to Gridinsoft’s trust scoring and some classification rules. Examining the age of records selected by those rules cannot independently validate age as a fraud predictor. There is also no representative control group of legitimate stores. The result is a description of selected records, not a probability that a domain of a given age is fraudulent or a ranking of the routes’ accuracy.

What did the additional checks establish?

Forty records were selected in advance for a limited content review and registry-date check. Content-review outcomes were fixed before examining their age, classification route or older review records. The reviewer examined up to six public HTML pages per site, without buying anything, submitting forms or executing JavaScript. This was an AI-assisted review by a single reviewer, without a second human adjudicator.

The concerns included contradictory policies, incomplete templates, contact problems and unverified identity. Fourteen negative results do not certify those sites as safe; the limited pass might miss conduct outside the pages examined. Similarly, zero confirmed cases does not establish that none of the sites engaged in fraud. The review did not measure a false-positive rate, and none of its outcomes was used to remove a record from the age analysis.

For the same 40 records, authoritative RDAP endpoints were located using IANA’s bootstrap registry. Thirty-five returned comparable registration events, all matching the saved date within one day. Four had no service in the captured bootstrap list and one returned an HTTP 429 rate-limit response. This supports the dates actually checked; it is not validation of every date in the 917-record analysis.

Why date agreement does not validate a fraud label

RDAP, the Registration Data Access Protocol, supplies registration events from the relevant registry service. The check required a matching domain name and a comparable registration event; transfer and last-change events were not treated as creation dates. Of the 35 matching saved dates, 24 came through Gridinsoft’s WHOIS parser and 11 through a saved VirusTotal report. Agreement across those checked records supports the registration-date field, rather than the store warning.

The 40-record check remained the same set throughout: failed registry requests and inconclusive content reviews were not replaced with easier cases. Thirty-seven of those 40 records had usable dates under the primary rules; 35 also had comparable RDAP results and two did not. Live registry and content checks occurred after the snapshot and did not overwrite the dates used for the age calculations.

The content review was independent of the sampled age fields and saved decision routes, but it was not fully blinded: the reviewer knew the selection category and the topic. The pass recorded 187 page-fetch attempts, including errors; some content was truncated and two initial URL-handling errors were retained. It did not test order fulfillment, payment flows or every statement on every page. Those limits matter when interpreting all four outcomes, especially the 14 cases where the pages examined did not support the warning.

Only two of the 1,000 records had a current structured first-party review on file, and both retained a suspicious classification. One was in the 40-record check; its earlier review had a broader scope, while the new limited pass did not support the warning from the pages it examined. That disagreement was retained. It does not establish that either assessment is a definitive fraud verdict.

How should you use domain age when checking a store?

A registration date answers a narrow question about the domain record. It does not by itself establish how long the current retailer has operated, whether ownership changed, or whether orders will be fulfilled. Our separate report on the reuse of expired domains gives a concrete example of why a domain’s history and its present use need separate attention; we did not establish that mechanism for this sample.

For a purchase decision, combine the exact address and registration history with the seller’s identity, contact details, policies and independent transaction evidence. The online shopping scam checklist covers those checks and what to do after a problematic purchase. Gridinsoft Website Reputation Checker can provide a dated warning and technical context, but the warning category should be read alongside its supporting evidence.

Methodology and scope

Snapshot: September 12, 2026, at 15:25:41 UTC. Window: the preceding 30 days, beginning August 13 at the same time. The selection frame contained 4,411 current Suspicious Shop records with no noindex flag and a save/update timestamp inside that window. It did not include every historical record, and its 4,411 rows were not separately deduplicated into registrable domains.

Selection and snapshot consistency

A fixed-seed SHA-256 ordering selected 1,000 records without replacement; all 1,000 selected normalized hostnames were different. Database fields were captured in a read-only transaction, then reconciled with saved report files and existing review records. The selected fields and file hashes were checked again for stability. This was a reconciled snapshot with a short consistency check, not an atomic historical backup of the whole service.

Age definition, exclusions and denominators

Age was the complete-day interval between the saved registration timestamp and the snapshot. Names were normalized consistently, and parent-domain dates were not substituted for tenant subdomains. Dates had to be positive, not future-dated, name-matched and not explicitly estimated. The chronology rules used a predefined one-day tolerance. Unknown dates remained unknown rather than becoming zero.

What the design can and cannot establish

The selection plan and age bands were fixed before extraction; the local plan was not externally preregistered. Four stored engine versions were represented. Differences between versions were not separated experimentally from the timing and composition of updates. The data do not reconstruct ages at first harmful activity, store survival after 30/60/90 days, the prevalence of fraud across the web, or the accuracy of the classifier. The aggregates were recalculated locally from the fixed sample and independently cross-checked with SQLite. The underlying records and review evidence are retained internally and are not publicly released.

This is a cross-sectional description of a finite, operationally selected set of current records. A 30-day save/update window is not a cohort of stores first detected during those 30 days: category history and past report contents could not be reconstructed for that purpose. The same limitation prevents estimates of disappearance after 30, 60 or 90 days. Following a fixed set prospectively would be needed to measure those outcomes.

Counts and denominators are reported alongside percentages, rounded to one decimal place; arithmetic uses unrounded values. Rounding may prevent displayed percentages from adding to exactly 100%. A conventional sampling margin of error would not resolve the main limits here—date availability, selection through the classifier and the absence of independent fraud confirmation—so the sensitivity analysis explicitly varies the unavailable ages and record mix instead.

Data availability: this article publishes aggregate findings, figures and the methodological description. Site-level records, raw source material, underlying datasets and reproduction code are not distributed. Readers can check the arithmetic of the displayed summaries, but cannot independently rerun the study from the article alone.

Suggested citation: Gridinsoft. Domain Age of Flagged Online Stores: A Study of 1,000 Records. September 12, 2026. Snapshot: September 12, 2026, 15:25:41 UTC. When quoting a percentage, retain the record group, usable-date denominator and Suspicious Shop classification boundary.

Study takeaway: the median was 100 days for 366 newly added records with usable dates and 544 days for 551 updated older records. Naming the group is part of reporting the result.

Reference

Internet Assigned Numbers Authority (IANA). RDAP Bootstrap Service Registry for Domain Name Space. Living registry, accessed September 12, 2026. Used to locate authoritative registration-data endpoints for the 40-record cross-check.