🔧 Custom landing pages

This is the technical companion to hosting your own landing page in front of your tchop app. It is written for whoever builds and operates the page. If you are deciding whether to do this at all, read the overview article first.

How the setup works

You host a page somewhere you control. tchop routes the root of your domain to it. Sign-up and login stay with the web app under the same domain.

Concretely, for a domain example.app:

• Your origin serves the page, normally on a hostname like landing.example.app.

• tchop's edge answers for example.app and forwards a defined set of paths to your origin.

• The web app keeps serving /auth/* and every logged-in route.

Visitors only ever see example.app.

Agree these four things with tchop before you build

• The origin hostname. Where your page will actually live.

• The list of forwarded paths. This is an explicit allowlist, not a catch-all. Anything not on it is answered by the web app, not by you.

• Which root files you need. Ask for all of them at once: /robots.txt, /sitemap.xml, /llms.txt, /security.txt, /favicon.ico, plus the Apple and Android app-association files if you use deep links. Adding them one at a time costs a round trip each.

• Who serves www. Your host, your builder or the edge. All three can do it. The failure mode is everyone assuming someone else does.

DNS

Create an explicit record for your origin hostname pointing at your server or your builder.

Check the zone for a wildcard first. Many tchop customers have a *.example.app CNAME pointing at the tchop edge. If one exists, your new subdomain appears to resolve immediately and then fails during the TLS handshake with tlsv1 unrecognized name, because the edge has no certificate for that name. It looks like a DNS problem and it is not. An explicit record at the specific name wins over the wildcard.

The same applies to www. If nothing explicit exists, it lands on the edge and fails the same way.

Certificates

Your origin needs a valid certificate for the origin hostname, and for www if you serve it. Most servers and every website builder handle this automatically once DNS points at them. Nothing on the tchop side is involved.

Which paths belong to whom

Do not build anything under /auth. Those URLs are not yours and the edge will not forward them.

What your page must do

• Link sign-up and login absolutely, to https://example.app/auth/signup and https://example.app/auth/login. Do not rebuild those forms. Accounts, passwords and social logins belong to the app.

• Carry imprint and privacy policy under their own URLs, linked from every page.

• Work at 320 pixels wide without horizontal scrolling.

• Set width and height on every image so nothing jumps while loading, and lazy-load anything below the fold.

The one that catches everyone: canonical

Your page is reachable under two hostnames, the public domain and your origin hostname. Search engines will find both, because every certificate you issue is published in public transparency logs and some crawlers read them.

Put a canonical link on every page pointing at the public domain, never at the origin hostname:

<link rel="canonical" href="https://example.app/">

This works regardless of which hostname served the request, and it is what consolidates the two. The same rule applies to og:image and any other absolute URL in your metadata: always the public domain.

Do not put a Disallow in robots.txt for your origin hostname. It blocks crawling, not indexing, and it prevents the crawler from ever reading the canonical. The URL can still appear as a bare link with no title.

Caching

Long cache lifetimes for static files, no cache for HTML, so a content change is visible immediately:

• Files under your assets path: public, max-age=604800, immutable

• HTML: no-cache, must-revalidate

If your server lets you define both a global rule and a path rule, make sure they are mutually exclusive. A global header and a path-scoped header can both match, and the global one usually wins, which silently leaves your images uncached.

Your 404 page

Serve your own 404 for unknown paths, and keep the status code at 404. Do not redirect to the homepage: a redirect tells search engines the URL exists, and it hides typos from the person who made one.

robots.txt and sitemap.xml

Both can be yours once the paths are forwarded. Two things to watch:

• Only one robots.txt can win. If the edge serves its own, yours is invisible, and the two can say opposite things. Compare the file you serve with the file the public domain actually returns, and keep them identical.

• Keep the sitemap to real pages. Three or four URLs is normal for a landing page. Reference it from robots.txt.

Privacy

Our recommendation is a page that loads nothing from third parties: fonts served from your own origin, no analytics, no embedded maps or videos, no cookies. That keeps the privacy policy short and means no consent banner.

If you build with a website builder, check what it loads in the background. Many pull fonts or analytics from third-party domains by default. That is allowed, but it changes your privacy position, and in Germany embedding Google Fonts has already been treated as a data protection violation by a court.

Before you go live

Run these against the public domain, not against your origin. Every line should match the expectation.

A quick way to see all of it: curl -s -o /dev/null -w "%{http_code} %{size_download} %{content_type}\n" https://example.app/<path>

Things we have seen go wrong

• A wildcard in the DNS zone making a broken subdomain look like a working one.

• A canonical pointing at the origin hostname, which tells search engines to prefer the wrong address.

• Cache headers overwriting each other, so large images are re-downloaded on every visit.

• An og:image on the origin hostname, so shared links show no preview.

• A root file that was never forwarded. An audit tool then reads whatever the edge returns and reports a defect in a file you never served.

• Restricting the origin to the proxy's IP address. Tempting, and it took a live site's legal pages down within seconds. The canonical already solves the underlying problem.

Questions

Your tchop contact can put you in touch with the team that configures the edge. If you send them the domain, the origin hostname and the list of root files you need, most of this is settled in one exchange.