Where the Contact Link Lives: 56 Pages, One Address, and a mailto Anchor on Only 4 Screens
I work on OnePassApps, so this is our own site and our own build. Every number below was measured on app.onepassapps.com today with plain curl and a real Chrome session on our own box - no estimates, and nothing about an
I work on OnePassApps, so this is our own site and our own build. Every number below was measured on app.onepassapps.com today with plain curl and a real Chrome session on our own box - no estimates, and nothing about anyone else's site.
There is one support address behind OnePassApps: [email protected]. This is what our 56 pages actually do with it, and the answer is not the same on every page.
What I measured
- The 56 URLs listed in https://app.onepassapps.com/sitemap.xml
- Each one fetched as plain HTML with curl
- Each one then opened in a real Chrome on our own server, left to settle for 9 seconds, scrolled to the bottom, and read again
That last step matters. The HTML we serve and the page a visitor ends up with are two different documents, and the contact link moves between them.
The served HTML carries the address, and no mailto at all
Across all 56 served documents:
- the literal string [email protected] appears exactly once per page - 56 occurrences over 56 pages
- that occurrence sits inside the JSON-LD, in the ContactPoint block for customer support
- 0 of the 56 documents contain a mailto: URL
- all 56 contain Cloudflare's /cdn-cgi/l/email-protection link
So nothing that reads our HTML directly gets a clickable address. The address is there as data, and as protected text.
The guide fleet: the address is on screen, and it is not a link
23 of the 56 URLs are the guide fleet - the /guides index plus the 22 /guides/ pages. After the page settles, all 23 have a
. Its nav element is labelled "Legal and help" and holds exactly five links:/terms, /terms#privacy, /terms#payments, /plans, /guides
That footer is identical on all 23 pages, and none of them links to /support. The contact line in those footers reads:
Published by OnePassApps. Guides describe the supported workflows and limits of the available apps. Contact [email protected].
The address is right there, in plain sight. It is not a link. There is no mailto: anchor anywhere on any of the 23 guide pages.
The app fleet: a footer on three pages out of thirty-three
The other 33 URLs are the app fleet - the home page, /voting, /plans, /terms, the seven studios and the 22 apps.
A
appears on only 3 of them: the home page, /voting and /plans. Where it appears, it is a different component. Its nav is labelled "Legal and support", not "Legal and help", and it carries seven links - the same five, plus /support and a mailto:[email protected].The two fleets do not share a footer. One is "Legal and help" with five links and no way to write. The other is "Legal and support" with seven links and one.
29 mailto anchors that are in the document but not on the screen
Every one of the 33 app pages does contain a mailto:[email protected] anchor. On 29 of them that anchor is the only one on the page, and it sits inside the fallback shell - the pre-JavaScript content the app replaces once it boots. Measured in the live DOM, that anchor has a bounding box of 0 x 0 pixels. It is in the document and not on the screen.
On 4 pages the mailto is a real, visible link: the home page, /voting, /plans and /terms. Three of those four are the pages with the footer.
The support page is reachable from three pages
/support answers HTTP 200 and is titled "Support and feedback - OnePassApps". It is linked from exactly 3 of the 56 pages: the home page, /voting and /plans - the three with the app-fleet footer.
/terms, by contrast, is linked from 23 guide pages and 5 app pages.
What I did not do
- I did not sign in, so every page was measured as a signed-out visitor
- I did not test a phone viewport, a screen reader, or a keyboard-only pass
- I did not measure anything except our own pages, and this post is about our own build
- I did not change anything on the site
If you want the same measurement on your own build, the recipe is short: fetch the sitemap, curl every URL, then open each one in a real browser and read the DOM after it settles. The served HTML and the settled DOM are different documents, and the contact link lives in the gap between them.
Our guide index: https://app.onepassapps.com/guides?utm_source=devto&utm_medium=community&utm_campaign=contact-route&utm_content=guides-link
Our support page: https://app.onepassapps.com/support?utm_source=devto&utm_medium=community&utm_campaign=contact-route&utm_content=support-link
Originally published by Dev.to WebDev. Aggregated on AIWithGhost for educational purposes β full credit and traffic to the original publisher.