IncomeWikiCategoriesSoftware
Website
Created by @namkyu · Updated Sep 2, 2026
Created by @namkyu · Updated Sep 2, 2026
A website can be launched with very little infrastructure cost, but operating one as a real public service requires more than writing code. Domain and DNS configuration, hosting, HTTPS, analytics, search indexing, authentication, backups, monitoring, payments, and monetization become separate operational concerns once the site goes live.
A website is also not a single business model. A content publisher, SaaS product, affiliate site, marketplace, community, and paid membership site can use similar infrastructure while having completely different revenue and cost structures.
Item | Practical starting point |
|---|---|
Development software | Free |
Google Analytics | Free for GA4 properties |
Google Search Console | Free |
Cloudflare | Free plan available |
HTTPS | Free options available |
Google Sign-In | Google Identity Services |
Custom domain | Paid; registration and renewal vary by TLD and registrar |
Hosting | Free tier, VPS, cloud, managed hosting, or self-hosting |
Main monetization | Advertising, subscriptions, affiliate commissions, sponsorships, paid listings, transactions, digital products, donations |
Search visibility | Crawling, indexing, and ranking are separate; publishing does not guarantee search traffic |
Main hidden work | Deployment, DNS, authentication, indexing, monitoring, backups, maintenance, moderation, and support |
A functioning website can therefore have very low software costs. The cost profile changes substantially when traffic, storage, database usage, email delivery, APIs, redundancy, payment processing, moderation, customer support, or paid acquisition increase.
A public website does not necessarily require paid cloud infrastructure.
Requirement | Minimum option | Cost | Priority | Notes |
|---|---|---|---|---|
Code editor | Visual Studio Code or equivalent | Free | Essential | For custom development |
Source control | Git + GitHub free account | Free | Recommended | Version control and deployment workflow |
Framework | Next.js, other open-source framework, or static HTML | Free | Optional | Depends on site type |
Database | PostgreSQL, Supabase, or another database | Free entry possible | Optional | Dynamic sites only |
Hosting | Free-tier host or existing hardware | $0 additional possible | Essential |
A locally functioning application is only one part of operating a website.
A typical production path is:
Application → Server/Hosting → Domain → DNS → HTTPS/CDN → Analytics → Search indexing → Authentication → Monitoring → Monetization
Each layer can fail independently.
For example, an application may be running correctly while the public site is unavailable because DNS points to the wrong address. A site may load normally for users while Google cannot index particular pages. Google login can work in development but fail on the production domain if the OAuth configuration does not match the deployed URLs.
This makes deployment and operations materially different from simply completing the application's code.
There is no single required hosting model.
Platforms such as Vercel, Cloudflare Pages, and Netlify reduce infrastructure work by handling deployment, HTTPS, and parts of the networking stack.
This is useful for developers who want to deploy directly from a Git repository without maintaining a Linux server.
The trade-off is that infrastructure pricing, usage limits, and platform-specific architecture become relevant as usage increases.
A VPS gives the operator substantially more control.
A typical custom stack can include:
Linux;
Doker;
a web application;
PostgreSQL;
a reverse proxy such as Caddy or Nginx.
The operator becomes responsible for updates, firewall configuration, database backups, storage, monitoring, and recovery.
An existing PC or server can host a public website for little or no additional hardware cost.
The operator must instead account for:
electricity;
residential or business internet reliability;
router configuration;
public IP or alternative networking configuration;
hardware failure;
storage failure;
backups;
power outages;
software updates;
remote recovery.
Self-hosting therefore reduces direct hosting expenditure but does not eliminate infrastructure cost or operational work.
Residential internet connections may also use dynamic addresses, blocked inbound ports, carrier-grade NAT, or other restrictions that affect public hosting. These conditions differ by internet provider and country.
A custom domain is separate from the server that runs the website.
The domain must point users toward the correct infrastructure through DNS.
Cloudflare provides a Free application-services plan with DNS, CDN, unmetered DDoS protection and Universal SSL. Its paid Pro plan is US$20/mo when billed annually or US$25/mo when billed monthly; Business is US$200/mo annually or US$250/mo monthly.
This means a small site does not necessarily need to purchase a separate CDN or public TLS certificate.
A common configuration is:
Visitor → Cloudflare → Origin server → Application
Cloudflare can proxy public traffic while the origin server remains separately managed.
For a self-hosted service, operators can restrict direct access to the origin and allow public web traffic through the proxy, provided the configuration does not unintentionally block legitimate traffic.
When a CDN or reverse proxy is used, there can be two separate encrypted connections:
Visitor → CDN/proxy → Origin
A valid edge certificate therefore does not by itself guarantee that the origin TLS configuration is correct.
example.com and www.example.com are different hostnames.
A production site should deliberately decide which is canonical and redirect the other when appropriate.
HTTPS, DNS records, reverse-proxy configuration, OAuth URLs, and application base URLs need to agree. A configuration can therefore work at:
https://example.com
while failing at:
https://www.example.com
if the second hostname has not been configured correctly.
Two Google services commonly used by website operators measure different things.
Service | What it answers | Cost |
|---|---|---|
Who visits the website and how they use it | Free for GA4 properties | |
How the website performs in Google Search | Free |
They are complementary rather than substitutes.
Other analytics products such as Plausible Analytics, Matomo, and Cloudflare Web Analytics can be relevant when privacy, data ownership, or lighter client-side scripts are priorities.
Google Analytics can measure website and application interactions across devices and platforms.
Useful website measurements include:
users;
sessions;
landing pages;
acquisition channels;
countries;
events;
conversions;
user paths.
GA4 properties are provided without charge under Google's Analytics terms.
Analytics does not tell an operator whether a page has successfully entered Google's search index. That is a Search Console function.
For a global website, analytics should also be interpreted geographically. Conversion rates, advertising value, purchasing power, payment methods, and user behavior may differ substantially between countries.
Google Search Console is Google's free tool for monitoring a site's presence in Google Search.
It can show:
whether Google can access the site;
crawl and indexing problems;
indexed and non-indexed URLs;
search impressions;
clicks;
queries;
countries;
devices;
links;
sitemap processing;
individual URL inspection.
It can also request recrawling of individual URLs.
A new website can be completely functional and accessible worldwide while still having little or no Google Search visibility.
These are separate stages.
Discovered → Crawled → Indexed → Served/ranked
A page being discovered does not mean it has been crawled.
A page being crawled does not mean it has been indexed.
A page being indexed does not mean it will rank for a useful query.
Google states that Search works through crawling, indexing and serving results, and that not every processed page is guaranteed to enter the index.
For a page to meet Google's minimum technical eligibility, Googlebot must not be blocked, the page must return a successful HTTP 200 response, and it must contain indexable content. Meeting those conditions still does not guarantee indexing.
Google also states that crawling after a request can take from several days to several weeks.
Repeatedly requesting recrawling of the same unchanged URL does not make Google crawl it faster.
Search visibility can also differ by country and language. A page that performs well for one geographic audience may have little visibility elsewhere because competition, language, search intent, and available results differ.
An XML sitemap provides search engines with URLs the operator considers important.
A simple entry can contain:
<url>
<loc>https://example.com/page</loc>
<lastmod>2026-08-23T00:00:00Z</lastmod>
</url>Google recommends absolute URLs in sitemaps.
A single sitemap is limited to 50 MB uncompressed or 50,000 URLs. Larger sites must split the URLs into multiple sitemaps and may use a sitemap index.
For a database-backed website, the sitemap can be generated automatically from published pages instead of being manually edited.
Sitemaps are particularly useful for new sites with few external links because crawlers may otherwise have fewer paths through which to discover pages.
However, sitemap submission is only a signal. Google explicitly states that it does not guarantee crawling or indexing.
RSS and Atom feeds can also be submitted as sitemap formats, but they are not required when an XML sitemap already provides the necessary URL discovery mechanism.
robots.txt controls which parts of a site crawlers may request.
A site can allow public content while excluding administrative or editing routes.
Example:
User-agent: *
Allow: /
Disallow: /api/
Disallow: /login
Disallow: /*/edit
Sitemap: https://example.com/sitemap.xmlAn incorrect rule can prevent search crawlers from accessing important content.
robots.txt and noindex also solve different problems: crawling controls whether a crawler may request content, while a noindex directive tells supported search engines not to include a page in search results.
A website that requires user accounts does not necessarily need to maintain its own password system.
Google Sign-In, based on Google Identity Services, lets users authenticate with an existing Google Account.
Google's current web setup requires an OAuth 2.0 client ID. The developer creates or selects a project in Google Cloud Console, configures OAuth branding/settings, and loads the Google Identity Services client library.
Production configuration can involve:
OAuth client ID;
application branding;
authorized domain;
JavaScript origin;
redirect URI;
consent configuration;
backend ID-token verification.
A typical production origin might be:
https://example.com
while an authentication framework may use a callback such as:
https://example.com/api/auth/callback/google
The exact callback depends on the application's authentication implementation.
A mismatch between the configured URI and the application's URI can prevent authentication even when the rest of the website operates normally.
Google Sign-In authenticates the Google user; it does not replace the website's own session and authorization logic. The application still decides what the authenticated user is allowed to do.
Authentication should also be distinguished from authorization to Google APIs. Google Identity Services separates signing a user into a website from requesting permission to access additional Google data.
Other representative authentication services include Auth0, Clerk, Supabase Auth, and Firebase Authentication.
Creating a Google Cloud project for an OAuth client does not mean the website must host its application on Google Cloud.
For example, the application may run on:
Self-hosted Linux server
while using:
Google Cloud project → OAuth configuration → Google Sign-In
The server itself can remain completely outside Google Cloud.
Likewise, Google Analytics, Google Search Console, and Google Cloud have different purposes despite all being Google services.
A small custom content or community website can realistically use a stack such as:
Layer | Example |
|---|---|
Application | Next.js |
Database | PostgreSQL |
Containers | Docker |
Reverse proxy | Caddy |
DNS/CDN | Cloudflare |
HTTPS | Caddy and/or Cloudflare |
Authentication | Google Sign-In |
Traffic measurement | |
Search monitoring | |
Transactional email | Resend, Amazon SES, or similar |
Error monitoring | Sentry or application logs |
A website is a distribution mechanism rather than a single business model.
Revenue depends on what the site provides and what economic action occurs after traffic arrives.
Model | Revenue event | Common fit |
|---|---|---|
Display advertising | Ad impression/click ecosystem | Content, Wiki, forum |
Affiliate | Referred purchase or action | Reviews, comparisons, guides |
Subscription | Recurring user payment | SaaS, premium information, tools |
Paid listing | Business pays for placement/listing | Directory, marketplace |
Transaction fee | Transaction completed | Marketplace/platform |
Sponsorship | Direct sponsor agreement | Community/content |
Digital product | Product purchase | Education, templates, data |
Donation/membership |
There is no useful global "average website income" that applies across websites because a personal blog, SaaS application, ecommerce marketplace, subscription publication, and financial comparison site generate revenue through fundamentally different transactions.
More useful economic measures depend on the model:
advertising → publisher revenue per 1,000 pageviews or sessions;
affiliate → commission per referred sale or action;
subscription → paying subscribers × net revenue per subscriber;
marketplace → transaction volume × take rate;
SaaS → customers × recurring revenue per customer;
sponsorship → contracted payment per placement or campaign.
These measures should not be combined into a single website-wide earnings benchmark.
Display advertising is one of the easiest monetization models to understand operationally because revenue can begin without building a proprietary payment product.
Google AdSense is one example, but advertising economics should be evaluated using publisher-side metrics such as RPM rather than advertiser CPM.
For a content site:
Page RPM = estimated publisher revenue / page views × 1,000
For AdSense for Content, Google states that publishers receive 80% of revenue after the advertiser platform takes its fee. When advertisers buy display ads through Google Ads, Google says publishers retain approximately 68% of advertiser spend.[1][1]This is Google's revenue-share structure, not a prediction of the RPM an individual website will earn.
The revenue-share percentage does not mean advertising earnings are geographically equal.
Actual publisher RPM can differ substantially according to:
visitor country;
advertiser demand;
topic;
season;
device;
traffic source;
ad viewability;
time on page;
ad placement.
A site with substantial traffic can therefore generate weak advertising revenue when visitors come from lower-value advertising markets or when the content has little commercial intent.
Advertising also creates a trade-off between monetization and user experience because additional placements can increase visual clutter and page weight.
Google's AdSense payment threshold also depends on the account's reporting currency. For accounts using U.S. dollars, the payment threshold is US$100; other currencies have their own thresholds.
Affiliate monetization works best when a page sits close to a purchasing decision.
Examples include:
product comparisons;
software comparisons;
hosting recommendations;
equipment guides;
business-service directories.
The economically important values are not raw traffic alone but:
Visitors × outbound-click rate × merchant conversion rate × commission
A smaller high-intent website can therefore be more valuable than a larger general-information site.
Actual commission rates and attribution windows should be checked against each affiliate program rather than assumed across the industry.
For example, the U.S. Amazon Associates program lists standard commission rates that vary substantially by product category, including 10% for Luxury Beauty, 4.5% for Physical Books, Kitchen and Automotive, and 3% for many Home, Pets, Sports and other categories.[2][2]These are U.S. Amazon Associates rates and should not be generalized to Amazon affiliate programs in other countries.
Subscriptions can reduce dependence on advertising but require a reason for users to pay repeatedly.
Web products commonly place payment around:
premium tools;
additional data;
advanced search;
saved workflows;
team features;
higher usage limits;
removal of advertising;
professional features.
This changes the important metric from page views toward paying conversion, churn, and revenue per customer.
A website can process recurring payments through Stripe, a merchant-of-record service, or another payment provider appropriate to the operator's country.
Hosted publishing platforms may add another platform fee. Substack, for example, charges publishers 10% of each paid-subscription transaction in addition to payment-processing and billing fees charged through Stripe.
Payment availability, processing fees, local payment methods, taxes, and currency-conversion costs can differ by country, so one country's payment economics should not be generalized globally.
Wiki and user-generated-content sites have additional monetization options because contributors can continuously expand the site's searchable content.
Fandom is an example of a for-profit Wiki platform whose business includes advertising and commercial partnerships.
Other knowledge/community projects may instead use advertising, donations, memberships, subscriptions, sponsorships, affiliate links, paid listings, or combinations of these models.
The existence of a large Wiki does not establish that a new Wiki can reproduce its economics. Community size, search distribution, moderation cost, accumulated content, brand recognition, and advertiser relationships are major differences.
A content-heavy website can accumulate pages that independently receive search impressions.
For example:
/wiki/topic-a
/wiki/topic-b
/wiki/topic-c
...Each page becomes another potential search entry point.
This makes structured Wiki, directory, and database models different from a small fixed marketing website: adding useful pages expands the site's searchable surface area.
However, creating URLs alone does not create search traffic. Google explicitly states that sitemap submission does not guarantee indexing, and indexing itself does not guarantee that a page will be served prominently for a query.
The economic value of search traffic also depends on what visitors do after arriving. Traffic to a high-intent comparison or purchase page can have very different economics from general informational traffic.
The first version of a website can be unusually cheap because many infrastructure components have free tiers.
Costs tend to appear as the service grows.
Common early expenses include:
domain registration and renewal;
VPS or hosting;
backup storage;
transactional email;
premium SaaS tools;
monitoring.
Domain prices differ by registrar and TLD rather than having a universal website-wide price.
Costs that can grow with activity include:
compute;
bandwidth;
database capacity;
object storage;
email volume;
AI/API calls;
monitoring/log retention;
payment processing.
A website using AI APIs, large media files, or heavy database queries can therefore develop significant variable costs earlier than a mostly static content site.
Websites collecting money normally pay payment-processing or merchant-of-record fees.
These fees differ by country, payment method, and provider.
For example, Stripe standard U.S. card pricing should not be treated as Stripe's universal global price. International cards, currency conversion, local payment methods, refunds, disputes, and subscription billing can also change the final processing cost.
For community and Wiki sites, infrastructure may eventually be cheaper than:
moderation;
spam handling;
These components are often absent from a local prototype but become more important once users depend on the site.
Representative error-monitoring options include Sentry, application logs, hosting-provider monitoring, and cloud observability services.
Websites that send account verification, password recovery, login links, receipts, or notifications can use services such as Resend, Amazon SES, SendGrid, or Postmark rather than operating their own mail server.
Important dynamic data should also have a recovery plan. This may include:
database backups;
uploaded files;
configuration;
source code;
off-server backup copies.
A backup is useful only if the data can actually be restored.
A site may work on one hostname but fail on another.
Apex and www records, certificates, redirects, reverse-proxy configuration, and application base URLs should describe the same production setup.
Localhost and the production domain are different OAuth environments.
Production origins and callback URLs need to be configured correctly.
Server logs or Search Console may show Googlebot requests while individual pages remain outside the index.
This is possible because crawling and indexing are separate stages.
This is expected because they measure different systems.
Analytics measures website usage; Search Console measures Google Search visibility and search-originating activity.
When a proxy/CDN sits between users and the origin:
User → CDN → Origin
either connection can fail.
An origin TLS problem can therefore produce an error even though the application process itself is running.
Production email can fail because of API credentials, sender-domain verification, DNS records, provider limits, spam filtering, or incorrect environment variables.
A functioning application does not guarantee reliable email delivery.
There is no universal license or registration requirement simply for putting a website online.
Actual legal and commercial requirements depend on the operator's country, customer locations, business model, data collected, payment activity, user age, industry, and content.
A basic public website should technically have:
a publicly reachable host;
a domain or provider URL;
valid HTTPS for normal production use;
working DNS;
a deployment process;
backups for data that cannot be recreated.
A website seeking Google Search traffic should additionally ensure that:
Googlebot is not blocked;
indexable pages return HTTP 200;
important pages contain indexable content;
internal links are crawlable;
canonical URLs are intentional;
important URLs are discoverable.
A website with accounts must additionally maintain application-level sessions, authorization, and account data even when an external identity provider handles authentication.
A commercial website may additionally need privacy disclosures, terms, tax handling, consumer disclosures, cookie or tracking consent, or other measures depending on the jurisdictions and activities involved.
Requirements from the United States, European Union, Korea, or another jurisdiction should not be assumed to apply globally.
A site can function correctly and still receive little search, social, referral, or direct traffic.
For organic search specifically, Google states that crawling can take several days to several weeks after a request, and neither a crawl request nor a sitemap guarantees indexing.
A project may launch using free analytics, CDN, SSL, frameworks, and database software but later incur hosting, storage, email, API, payment-processing, and moderation expenses.
Self-hosting can reduce hosting bills but makes power, internet connectivity, hardware, firewall configuration, updates, security, backups, and recovery the operator's responsibility.
Search engines, payment processors, CDNs, identity providers, ad networks, affiliate programs, email providers, and APIs can change pricing, policies, limits, eligibility, or availability.
Advertising demand, affiliate conversion, purchasing power, payment methods, and subscription conversion can differ substantially between countries.
Identical traffic volumes therefore do not necessarily produce identical revenue.
Limits depend on provider |
DNS/CDN | Cloudflare Free | Free | Recommended | DNS, CDN, DDoS protection and SSL |
HTTPS | Let's Encrypt, Cloudflare Universal SSL, or hosting-provider certificate | Free | Essential | Public sites should use HTTPS |
Analytics | Free | Recommended | Visitor and acquisition measurement |
Search monitoring | Free | Recommended | Google crawling, indexing and search performance |
Authentication | Google Sign-In or application-managed accounts | Free entry possible | Optional | Needed only for user accounts |
The major unavoidable cash expense for many small custom websites is therefore the domain rather than the development stack itself. A developer who already owns suitable hardware can also self-host, although this transfers uptime, networking, backups, security, and hardware-failure responsibility from a hosting company to the operator.
A custom domain is not technically required when a hosting provider supplies a subdomain, but it is normally part of a serious public or commercial deployment.
Payments
Stripe or an appropriate regional provider |
Search discovery | XML sitemap + crawlable internal links |
Most of these components have a free option or are open-source. Infrastructure cost therefore does not necessarily become large before a site has substantial traffic.
The more important early cost can be development and maintenance time.
Voluntary or member payment |
Community, open knowledge |
Traffic alone is therefore not revenue.
Two websites with the same monthly visitors can have radically different economics depending on visitor geography, purchase intent, advertising niche, conversion rate, pricing, and revenue model.
abuse prevention;
copyright requests;
user support;
content verification.
These costs are easy to omit from an initial hosting calculation.