GEDCOM Error Propagation: How Bad Family Tree Data Spreads

What is GEDCOM error propagation?

GEDCOM error propagation is the chain reaction that happens when a single mistake in a family tree spreads outwards through linked records. Because GEDCOM files store people, families, sources and events as a graph of cross-references, one bad fact rarely stays isolated.

A misattributed parent, a duplicated individual, or a date typed as 1798 instead of 1898 can quietly invalidate hundreds of downstream facts: ancestry lines, sibling sets, census matches, DNA cousin paths and migration timelines all rely on the integrity of the records they point to.

The problem compounds every time the file is exported, merged into another tree, or imported into a collaborative platform. Errors get copied, re-shared, and re-imported by other researchers - which is why the same bad date or wrong father shows up in dozens of unrelated trees online.

How errors spread through family trees

Errors propagate along three main paths:

• Within your own file - A wrong link at one node changes every relationship calculated through it. Set the wrong father on a single person and every cousin path, ahnentafel number and ancestral surname downstream is now incorrect.
• Between files via GEDCOM export/import - Genealogy software preserves the structure of bad data on export. When you share a .ged file, you share the errors with it.
• Across the wider genealogy ecosystem - Online trees frequently copy from each other. A single wrong parent on a popular ancestor can be replicated into thousands of trees within months, and once it's "everywhere" it starts to look like consensus.

The deeper an error sits in the tree (closer to the root), the more facts it eventually corrupts. An error on a 5x great-grandparent can poison an entire branch.

Duplicate people and bad merges

Duplicates are the single biggest source of cascading errors. They usually appear when:

• The same ancestor is entered twice with slightly different spellings or dates
• Two trees are merged and matching individuals are not deduplicated
• A "smart match" or hint is accepted without comparing all facts

A bad merge is worse than a duplicate left alone. Merging two records that are *not* the same person fuses two unrelated families into one, attaches the wrong children to the wrong parents, and creates impossible date overlaps that ripple outwards.

Use a duplicate finder that compares names, dates, places and parents before merging - not just names. If two candidates have mismatched parents or non-overlapping life spans, they almost certainly aren't the same person.

Wrong parents and cascading ancestry errors

Parent links are the load-bearing structure of a genealogy database. Get one wrong and:

• Every ancestor above that point belongs to the wrong family
• DNA matches that *should* line up no longer do
• Surname distributions, migration paths, and ethnic origins all shift
• Cousin calculations for living relatives become meaningless

This is the single highest-impact class of error. Before accepting a parent-child link, confirm it with at least one direct primary source (birth record, baptism, will naming the child) - not just another tree.

Impossible dates

Date errors are the easiest to detect automatically and the easiest to introduce by accident. Common offenders:

• Death before birth - usually a typo or swapped fields
• Children born before parents or after the mother's death
• Marriages at age 8 - often a transcription off by 100 years (1798 vs 1898)
• Future death dates - leftover placeholders or import bugs
• Lifespans over 120 years - usually two people merged into one

Even a single date error distorts every calculation that depends on it: lifespan averages, generation length, census gap detection, and the chronological ordering of events.

Place-name errors

Place names rarely look broken, but they propagate quietly. Common patterns:

• The same town spelled five different ways across one tree
• Modern country names applied to events that pre-date the country
• Counties, states or parishes attached to the wrong jurisdiction
• Free-text notes ("near the church") sitting in the place field

Bad places break geographic analysis - migration maps go nowhere, location clustering misses obvious patterns, and census-record searches return zero hits because the place string doesn't match any real archive index.

Standardise place names to a consistent format (e.g. *Town, County, Country*) and use historically accurate jurisdictions for the date of the event.

How to audit a GEDCOM before importing or sharing

Before you import a GEDCOM into your main tree - or send it to a relative - run these checks:

1. Scan for impossible dates - births after deaths, future events, parent younger than child.
2. Look for duplicates - especially on common surnames and recurring forenames within a family.
3. Spot-check parent links on the deepest ancestors - errors here have the largest blast radius.
4. Review unsourced facts - any fact without a citation is a candidate for verification, not propagation.
5. Standardise place names before they spread further.
6. Check unlinked individuals - orphan records often signal a broken merge or import.

Do this *before* the file mixes with your existing data. Once errors are merged into a large tree they become exponentially harder to extract.

Run a free GEDCOM error check

GEDminer audits a .ged file entirely in your browser - the file never leaves your device - and reports impossible dates, duplicate candidates, missing vitals, unlinked individuals, place-name inconsistencies and structural problems in seconds.

Upload your file, open the Integrity tab, and work through the flagged issues from highest severity downwards. Fix the problems in your main genealogy software, re-export, and re-scan until the report is clean. Then - and only then - share or merge the file.

A five-minute audit before you share is worth weeks of cleanup later, both for you and for everyone downstream of your tree.