Most small sites do not need a full analytics project on day one. They need a few honest answers.
Did anyone open the link? Which page did they land on? Did the traffic come from a client email, a social post, a search result, or a QR code? Was the audience mostly on phones? Did a tiny PDF or image-heavy page burn more bandwidth than expected?
That is the job of static site analytics. Not to replace product analytics. Not to turn every portfolio or preview page into a dashboard project. Just to show what happened after the link left your hands.
Start with the question the site was supposed to answer
Analytics gets messy when every number looks equally important.
A static site usually has a narrower job than a full web app. It may be a portfolio, a student project, a launch page, a docs update, a resume site, a client preview, or an AI-generated page that needs review. The first analytics pass should match that job.
| Site type | First useful question | Metrics to check first |
|---|---|---|
| Portfolio | Did the person I sent it to open it? | Visitors, referrers, top pages, device mix |
| Campaign page | Which source is sending useful traffic? | Referrers, UTM-tagged URLs, top pages, countries |
| Docs or changelog | Are people landing on the right page? | Top pages, referrers, paths with unexpected traffic |
| Client preview | Did reviewers open the latest version? | Recent visits, countries, devices, top pages |
| Student project | Can the teacher open it from outside your laptop? | Page views, device/browser mix, outside access |
| Image-heavy microsite | Is bandwidth becoming the problem? | Bandwidth, top pages, file size checks |
If you cannot name the question, the dashboard will not help much. You will just stare at a line chart and hope it means something.
Page views and visitors are different signals
Page views count loads. Visitors estimate people or browsers.
Both are useful, but they answer different questions. A page can have 100 page views from a handful of people refreshing, testing, or browsing several pages. Another page can have a healthier audience even when the raw page-view count looks similar.
For static sites, a practical read looks like this:
| Metric | Good for | Easy mistake |
|---|---|---|
| Page views | Overall activity and page-level demand | Treating refreshes as new people |
| Unique visitors | Rough audience size | Treating it as a perfect people count |
| Top pages | Which URLs are actually being opened | Only checking the homepage |
| Bandwidth | Cost and asset weight pressure | Ignoring large media until traffic arrives |
Analytics tools define these metrics differently. Google Analytics 4 centers reporting around events such as page_view, while simpler tools often present visits, pageviews, referrers, locations, and devices more directly. The exact vocabulary changes. The reading habit does not: compare related metrics instead of trusting one number alone.
On DeployPages, project analytics exposes page views, estimated visitors, bandwidth, top pages, referrers, countries, devices, browsers, operating systems, and recent visit logs. That is enough for the first launch read without adding another script to the static files.
Referrers tell you whether distribution worked
Most small launches fail quietly. The page is live, the link works, and nothing happens because the distribution step was weak.
Referrers help separate those problems.
If the page has almost no traffic, the issue may not be the page. It may be that the link never reached the right channel. If one referrer sends most visits, that channel deserves a closer look. If traffic appears as direct, that may include private messages, email clients, copied links, or apps that hide referrer data.
Use referrers with a little skepticism:
| Referrer pattern | What it may mean | What to do next |
|---|---|---|
| Mostly direct | Private shares, email, QR scans, copied links, or missing referrer headers | Add UTM parameters for future shares |
| One social site dominates | The post worked, or one person reshared it | Check whether top pages match the campaign goal |
| Search starts appearing | The page is being discovered outside the original share | Review title, description, and custom domain setup |
| A client or internal domain appears | Stakeholders are reviewing it | Keep that traffic separate from public launch judgment |
| Unknown or spammy referrers | Noise, bots, or unwanted traffic | Do not redesign the page around it |
If you plan to share the same static page in ads, email, QR codes, and social posts, use consistent campaign URLs. DeployPages includes a UTM builder for that. UTM tags will not make analytics perfect, but they reduce guesswork when the same link moves through several channels.
Device and browser data are design feedback
Static sites often get reviewed on a laptop and opened by everyone else on a phone.
That mismatch matters. A portfolio grid that looks careful on desktop may become a long scroll on mobile. A campaign hero that fits a wide monitor may push the call to action below the fold on a small screen. A PDF-style resume page may look fine in Chrome desktop and feel cramped in a mobile browser.
Device, browser, and operating system data should not drive every design decision. They should tell you where to test next.
If 70% of visits are mobile, test the real link on a phone before rewriting the copy. If Safari iOS appears often, check image loading, video behavior, and tap targets there. If a client review came from an older desktop browser, keep the page simple enough that the review does not become a compatibility conversation.
This is where static site analytics is more useful than vanity traffic. It tells you where the page is being experienced, instead of leaving you with a counter that went up.
Top pages catch broken assumptions
A static site can have one intended entry point and several real entry points.
That happens when people share a deep link, search engines pick up a specific page, QR codes point to a subpath, or an old campaign URL keeps circulating. If you only check homepage traffic, you miss the actual door people are using.
Top pages are especially useful after:
- Replacing a temporary preview URL with a custom domain.
- Uploading a new version with changed paths.
- Moving a GitHub Pages site, docs site, or portfolio.
- Sharing separate links for ads, email, and social posts.
- Publishing an AI-generated site where navigation may include placeholder routes.
If a top page is not the page you expected, do not treat that as a failure by default. It may be a better landing page than the one you planned. But if the top page is an old path, a missing asset route, or a dead download link, fix the routing before you spend time tuning the homepage.
Bandwidth is the metric people notice too late
Bandwidth looks boring until it becomes the reason a small site feels expensive or slow to move around.
Static sites are cheap to serve compared with server-rendered apps, but large images, video backgrounds, exported design assets, and uncompressed PDFs can still matter. A single 8 MB hero image may not look alarming during a private review. Put it in front of a campaign audience and the pattern changes.
Watch bandwidth when:
- The site uses high-resolution screenshots, portfolio images, or product photos.
- A PDF, deck, menu, or media file is hosted inside the site.
- A campaign or social post sends a traffic spike.
- You are close to a plan limit.
- Mobile visitors are the main audience.
Bandwidth does not tell you which asset is too large by itself. It tells you when the site deserves an asset pass. After that, check image dimensions, compression, lazy loading, and whether heavy files belong on the first page at all.
Built-in analytics first, heavier analytics later
There is a reasonable time to add Google Analytics, Plausible, Fathom, Simple Analytics, PostHog, or a product analytics stack. It is just not always the first hour after a static page goes live.
For many static sites, the first questions are simpler:
- Did the page get opened?
- Which link or channel sent the visit?
- Which URLs did people hit?
- Are visitors mostly on mobile or desktop?
- Is traffic coming from the expected countries?
- Is bandwidth behaving normally?
Built-in analytics is a good first layer because it is tied to the deployment and does not require editing the shipped files. You can upload a folder, get a preview URL, share it, and still read the first launch signals from the project dashboard.
Add a heavier analytics stack when you need things DeployPages analytics is not trying to be: custom events, funnels, attribution modeling, logged-in user behavior, A/B tests, ecommerce events, or deep product telemetry.
The split is healthy. Deployment analytics tells you whether the published site is being reached. Product analytics tells you what users do inside a product after they arrive.
A practical first-week review
For a new static site, review analytics on a simple schedule.
| Timing | What to check | Why |
|---|---|---|
| First hour | Page opens, basic visits, obvious path mistakes | Catch broken links before more people see them |
| First day | Referrers, device mix, top pages | See whether distribution and layout match the audience |
| First week | Trend, countries, bandwidth, repeat top pages | Decide whether to improve, replace, or leave the page alone |
| After a new upload | Compare top pages and traffic shape | Make sure the update did not break the working path |
| After domain launch | Watch search, direct traffic, and old URLs | Confirm the public address is taking over from the preview link |
This does not need to become a ritual. A static site is often successful precisely because it stays simple. The goal is to catch the few signals that change your next move.
How DeployPages fits this workflow
DeployPages treats analytics as part of the publishing path, not as a separate project you have to wire up before the first share.
You can publish a static folder, ZIP, AI-generated export, page that links to a PDF, or framework build output, then check visits, referrers, top pages, countries, devices, browsers, operating systems, bandwidth, and recent request details from the console. The same project can later grow into custom domains, password protection, instant rollback, or CLI deploys.
That order keeps the first launch lightweight. Publish the page, see whether anyone opens it, then decide what the project deserves next.