Router databases become unreliable when a fact that applies to one old model is presented as the default for an entire brand. Our editorial rule is simple: the more specific the claim, the more specific the evidence must be.
Our preferred source order
- Current manufacturer manual or support article for the exact model or product family.
- ISP/provider documentation when the hardware is carrier-supplied or customized.
- Manufacturer product label or setup guide when the relevant value is designed to be printed per device.
- Reputable secondary documentation only when primary documentation is unavailable, clearly labelled as secondary.
- Community reports as a lead, not as a universal fact. Community-only values are labelled accordingly and should be checked against the device.
What we do not infer?
We do not treat an IP address as proof of a username/password. We do not assume every model from one brand uses the same factory credential. We do not change a “last verified” date merely to make a page appear fresh. We do not publish a model-specific default when the source only describes a different hardware revision.
Why model and revision scope matters?
Manufacturers change setup flows over time. Older devices may have shipped with a universal credential while newer devices force the owner to create an admin password at first setup or print a unique credential on the label. ISP firmware can also change the local address and hide settings that exist in the retail firmware.
How uncertain device data is handled?
When a model, hardware revision, provider firmware, or credential cannot be confirmed, it should not be presented as a universal default. The useful response is to narrow the claim, identify the exact device, and keep the unverified value out of user instructions until it can be checked.
Corrections
If a source changes or a reader identifies a mismatch, the correction should update the factual field, its scope, and the verification date together. An old page should be corrected, consolidated, redirected, or removed rather than padded with generic text.
Product reviews are separate
This methodology page describes documentation and data verification. We do not claim hands-on performance testing for a router unless a review page explicitly explains the test hardware, firmware, environment, measurements, and date. Documentation research and physical product testing are different kinds of evidence.
For the site-wide policy, see Data Methodology and Editorial Policy.
Publication gate for router database pages
A page should be indexable only when it has a clear user task, enough original explanatory content and evidence for any device-specific claims. A private IP can be documented as private using standards; a brand/IP association needs manufacturer/provider/manual evidence; credentials need exact device evidence.
Freshness
Recheck manufacturer/ISP documentation when firmware/security practices change. Store the last-reviewed date and source. If a claim becomes uncertain, downgrade or remove it rather than preserving an obsolete “default” for traffic.
Corrections
Readers should have a path to report model/revision/provider differences. Corrections are evaluated against primary sources and the page should clearly distinguish confirmed, provider-specific and community-reported information.