Deploying and Optimizing Websites

Table of Contents

• Module 1: Deploying and Hosting a Website
  • The World Wide Web and HTTP
  • How the Internet Enables Web Access
  • Understanding Web Servers
  • Web Hosting Models and Cloud Computing
  • Comparing Popular Web Hosting Providers
  • Demo: Creating a Site with a Traditional Web Host (GoDaddy)
  • Demo: Deploying a Website to GoDaddy Using FTP
  • Demo: Creating a Site with a Cloud Provider (Azure App Service)
  • Demo: Deploying a Website to Azure Using Zip Deploy
• Module 2: Configuring Your Deployed Website
  • Understanding Domain Names and DNS Registration
  • Demo: Configuring a Custom Domain Name in GoDaddy
  • Demo: Configuring a Custom Domain Name in Azure
  • Understanding HTTPS, SSL, and TLS
  • Demo: Configuring SSL in GoDaddy
  • Demo: Configuring SSL in Azure App Service
  • Performance Optimization Fundamentals
  • Demo: Using DevTools/Lighthouse to Measure Page Load
  • Demo: Resizing an Image and Retesting Performance
• Module 3: Search Engine Optimization
  • How Search Engines Work
  • Understanding Search Engine Optimization
  • Spam Policies: What Not to Do
  • Search Engine Crawlers, Sitemaps, and robots.txt
  • Demo: Creating a Sitemap.xml
  • Demo: Submitting a Sitemap to Google Search Console
  • Exploring the Google Search Console
  • Keyword Targeting and Search Intent
  • Exploring Keyword Research Tools
  • Structured Data for Rich Results
  • Demo: Deploying and Testing Structured Data
• Summary

Module 1: Deploying and Hosting a Website

This module covers how to deploy and host a website on different types of hosting platforms, from traditional shared hosting to Platform-as-a-Service cloud offerings.

The World Wide Web and HTTP

The World Wide Web and the Internet are often used interchangeably, but they are different things. The World Wide Web (the Web) is an information system that enables content sharing over the Internet through user-friendly mechanisms such as web browsers. It allows documents and other web resources to be accessed according to the rules of the Hypertext Transfer Protocol (HTTP).

In short: the Web runs on top of the infrastructure provided by the Internet, and it uses HTTP as its sharing protocol. Documents and media are made available through web servers and accessed through web browsers (the client software). Servers and resources on the Web are identified and located through Uniform Resource Locators (URLs).

A basic request/response cycle works like this:

1. A user types a URL (e.g., http://somesite.com/index.html) into a browser.
2. The URL encodes the protocol (HTTP), the domain name of the web server (somesite.com), and the resource requested (index.html).
3. Because the browser and server both understand HTTP, the browser issues an HTTP GET request — the method typically used to retrieve a resource. Other HTTP methods exist for other purposes (e.g., submitting data).
4. The server receives the GET request and returns the requested document in an HTTP response.
5. The browser parses the HTML. While it loads, it discovers references to linked files (CSS, JavaScript, images, etc.) and issues additional HTTP requests to retrieve them.
6. Once the page is loaded, there is no persistent connection — the browser only reaches out to the server again when it needs to interact with the site again (e.g., the user clicks a link, which may point to a different server entirely).

sequenceDiagram
    participant U as User
    participant B as Browser
    participant S as Web Server

    U->>B: Types URL (http://somesite.com/index.html)
    B->>S: HTTP GET /index.html
    S-->>B: HTTP 200 response (HTML document)
    B->>B: Parse HTML, discover linked CSS/JS/media
    B->>S: HTTP GET /styles.css
    S-->>B: HTTP 200 response (CSS)
    B->>S: HTTP GET /script.js
    S-->>B: HTTP 200 response (JS)
    B->>U: Render fully loaded page

This simplified view leaves out many implementation details: how the browser locates the server, what happens with large downloads or interrupted connections, what happens if the resource or server isn’t found, how IP addresses work, what DNS does, and why some URLs use HTTPS. Those topics relate to how the underlying Internet works.

How the Internet Enables Web Access

The Internet is a network of networks built from hardware and protocols.

• Inside an office or home, computers connect to a Local Area Network (LAN). Traffic within the LAN and out to external destinations is managed by a router.
• The router connects to the Internet through a modem, which is provided by an Internet Service Provider (ISP).
• The ISP has its own network of business and consumer customers and routes traffic either within its network or out to a larger, regional ISP.
• Regional ISPs connect to even larger networks called the backbone of the Internet — companies that operate networks spanning cities and countries, using large-scale routers to move traffic worldwide.

flowchart LR
    A[Your Computer] --> R1[Home/Office Router]
    R1 --> M[Modem]
    M --> ISP[ISP Router/Network]
    ISP --> RISP[Regional ISP Network]
    RISP --> BB[Internet Backbone]
    BB --> RISP2[Destination Regional ISP]
    RISP2 --> ISP2[Destination ISP]
    ISP2 --> WS[Web Server]

All of this works because of layered protocols:

• HTTP is understood only by the browser and the web server, and it is built on top of TCP and IP.
• IP (Internet Protocol) gives every device on the Internet a unique address. IPv4 is still the most common version, made up of four octets. Routers use the structure of these addresses to determine which network an address belongs to.
• When a browser requests a resource, a data package is assembled that includes the destination IP address (the web server) and the source IP address (so the server knows where to reply). Routers inspect these packages to route traffic intelligently. In reality, data is broken into smaller packets (roughly 1,500 bytes each), which may travel different paths across the Internet and are reassembled on arrival.
• TCP (Transmission Control Protocol) is responsible for breaking data into packets, reassembling them on the receiving end, and re-sending any packet that gets lost in transit.
• DNS (Domain Name System) resolves the human-readable domain name typed into the browser into the numeric IP address of the destination web server. DNS servers across the Internet are queried in a hierarchy — if one doesn’t know the mapping, it asks another further up the chain, until the mapping is found or an error is returned.

sequenceDiagram
    participant B as Browser
    participant DNS as DNS Resolver Hierarchy
    participant WS as Web Server

    B->>DNS: Resolve somesite.com
    DNS-->>B: IP address of web server
    B->>WS: TCP/IP packets (GET request, packaged with source/destination IP)
    WS-->>B: TCP/IP packets (HTTP response, reassembled by TCP)

Understanding Web Servers

A website is hosted on a web server — a physical computer that someone owns and maintains, or (more commonly) rented space on a web server from a hosting provider.

Running your own web server requires:

• Physical security for the machine, plus electricity, cooling, and networking.
• Storage, either local or over a network share.
• Enough memory/CPU for however many sites and how much processing they require.
• An operating system — typically Windows Server (running Internet Information Services, or IIS) or a Linux distribution (running Apache or similar software).
• A runtime for dynamic sites — e.g., ASP.NET, Java, Ruby, or PHP — which needs installation and maintenance if the site does more than serve static files.
• Networking components such as firewalls and an application proxy to publish the site and mitigate denial-of-service attacks.
• Ongoing patching of the OS, web server software, proxies, and firewalls, plus eventual hardware replacement.
• Additional servers/software if the site uses a database.

A single physical server typically hosts multiple virtual servers that share its resources; each virtual server runs its own web server software and can host one or more sites, depending on the hosting model.

All of this is usually handled by a team of server administrators and is a significant ongoing cost — which is why most organizations rent hosting instead of running it themselves.

Web Hosting Models and Cloud Computing

There are several broad categories of web hosting:

Traditional web hosting — you pay a hosting provider to host your files on their web servers. You get a certain amount of space and bandwidth per month, a web interface to upload files and perform basic configuration, and often the option to purchase a custom domain name and an SSL certificate.

Cloud computing — a newer model (dating to the mid-2000s), offered by providers such as AWS, Microsoft Azure, and Google Cloud. Cloud computing breaks down into three service models based on how much responsibility/control you retain:

flowchart TB
    subgraph IaaS["Infrastructure as a Service (IaaS)"]
        direction TB
        I1["You manage: OS, runtime, web server software, app files, data"]
        I2["Provider manages: virtualization, physical servers, storage, networking"]
    end
    subgraph PaaS["Platform as a Service (PaaS)"]
        direction TB
        P1["You manage: application code, configuration, scaling rules"]
        P2["Provider manages: OS, web server software, runtime patching, VM maintenance"]
    end
    subgraph SaaS["Software/Website as a Service"]
        direction TB
        S1["You manage: content via drag-and-drop tools/templates"]
        S2["Provider manages: everything else, including the platform and hosting"]
    end

• Infrastructure as a Service (IaaS) — you pay for virtual servers hosted by the cloud provider. You can create virtual networks, security rules, traffic routing, application proxies, and databases — essentially everything you could do on-premises, minus physical hardware maintenance. You install and update the web server software and runtime yourself, and you can upload files directly onto the VM’s operating system or to attached/cloud storage.
• Platform as a Service (PaaS) — the cloud provider maintains the web server itself. You still configure the app and choose from multiple deployment methods, but you cannot log into the underlying VMs. You can typically scale the number of servers up or down (manually or automatically, e.g., based on CPU usage) to handle demand spikes such as a holiday shopping season. PaaS offerings (like Azure App Services) usually integrate with a wide range of complementary managed services — PaaS databases (SQL Server, MySQL), blob/file storage, API management, service buses for microservices, and identity/security services.
• Website as a Service — the hosting provider offers drag-and-drop tools and templates so you don’t have to write HTML at all. Examples include e-commerce platforms (Shopify, Wix) and content management systems (WordPress) with specialized hosting.

Traditional web hosting is often easier and cheaper if all you want to do is upload a website; PaaS/IaaS matter more once an organization needs complex, integrated cloud services.

Comparing Popular Web Hosting Providers

Based on market share (number of sites hosted, customers, domains registered, and traffic handled), the most prominent hosting brands include:

Before choosing a traditional web hosting company, compare their plan features carefully — supported runtimes (PHP, Python, ASP.NET), supported databases (MySQL, MariaDB, SQL Server), storage/bandwidth limits, and the length of the commitment term, since pricing is often quoted per month but billed over multi-year terms.

A key takeaway: most web hosting runs on Linux to keep provider costs down, which is fine for ASP.NET Core (cross-platform), but a specific runtime still needs to be installed/available — always confirm this before committing to a plan.

Demo: Creating a Site with a Traditional Web Host (GoDaddy)

Steps to purchase a web hosting plan and provision a new site:

1. Navigate to the hosting provider’s Web Hosting plans page (as opposed to Website Builder, WordPress Hosting, or VPS Hosting).
2. Compare the available tiers — number of websites allowed, storage, uptime guarantee (e.g., 99.9%), unmetered bandwidth, and automatic daily backups.
3. Note plans oriented at specific runtimes (e.g., a “Windows VPS with Plesk” tier for ASP.NET workloads) versus the default Linux-based shared hosting (PHP/MySQL/Python).
4. Add the selected plan to the cart, choose a commitment term (longer terms are usually cheaper per month but compare renewal pricing), and complete checkout with an account and payment method.
5. From the account dashboard, open My Products → Web Hosting → Manage, then choose to create a new (non-WordPress) site.
6. Select the hosting region closest to the expected audience for better performance.
7. Provisioning takes a few seconds; you land on a dashboard showing a default URL, admin login information, and links to hosting tools (such as the control panel).

Demo: Deploying a Website to GoDaddy Using FTP

With the hosting plan created, the goal is to replace the provider’s default placeholder page with a real site.

1. Open cPanel Admin from the hosting dashboard. This exposes: IP address/statistics, File Manager, FTP Accounts, MySQL databases, domain management, installable software (Perl, PHP packages, Python, Ruby), a security section, email management, and one-click app installers (WordPress, Drupal, Joomla, phpBB).
2. Open File Manager to see the public_html folder — the web root for this hosting account. Each customer is scoped to their own root folder; you cannot see other customers’ files (unless on a dedicated server).
3. Files can be uploaded directly through cPanel’s File Manager (drag-and-drop or file picker), but this method only uploads individual files, not whole folder trees. To deploy a full folder structure this way, compress the site into a .zip file, upload it, then use Extract inside File Manager.
4. The more common and folder-friendly approach is FTP (File Transfer Protocol):
   • In cPanel, go to FTP Accounts and create a new FTP login (e.g., admin) with a strong password.
   • Scope the account’s folder access — grant access to the hosting root (or just public_html) depending on how much needs to be managed.
   • Note the FTP server hostname, username, and port (usually 21) shown under “Configure FTP Client”.
5. Install a free FTP client such as FileZilla.
6. In FileZilla, enter the FTP host, username, password, and port, then click Quickconnect. Accept any certificate name-mismatch warning (expected when the default hosting hostname doesn’t match the certificate).
7. Navigate the remote pane to public_html, delete any old/default files, then drag the local website files (HTML pages, CSS, images, downloads, etc.) from the local pane into the remote pane. FileZilla shows per-file transfer progress and creates subfolders automatically.
8. Refresh the site’s URL in a browser to confirm deployment. If no filename is specified in the URL (i.e., the path ends in /), the web server returns a configurable default document — commonly index.html, default.html, or home.html.

flowchart LR
    Local[Local Website Files] -->|FTP upload via FileZilla| Remote[public_html on Web Server]
    Remote --> Browser[Browser requests domain]
    Browser -->|No file specified| Default[Server returns default document, e.g. index.html]

Example of the deployed site’s index.html structure (a static HTML/CSS storefront used throughout the demos):

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8">
    <title>Welcome to the Pie Shop!</title>
    <meta name="description" content="Store front for an online pie shop">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <link rel="icon" type="image/png" href="favicon.png">
    <link rel="stylesheet" href="styles.css">
</head>
<body>
    <div id="wrapper">
        <header id="main-header">
            <nav>
                <ul>
                    <li><a href="index.html">HOME</a></li>
                    <li><a href="pieoverview.html">PIES</a></li>
                    <li><a href="contact.html">CONTACT</a></li>
                    <li><a href="about.html">ABOUT</a></li>
                </ul>
                <input type="search" class="search-box" placeholder="Search our store" />
            </nav>
        </header>
        <div id="main-content">
            <aside id="left-menu">
                <ul class="small-menu">
                    <li><a href="pieoverview.html">All pies</a></li>
                    <li><a href="cheesecakes.html">Cheese cakes</a></li>
                    <li><a href="fruitpies.html">Fruit pies</a></li>
                    <li><a href="seasonalpies.html">Seasonal pies</a></li>
                </ul>
            </aside>
            <main id="main">
                <article>
                    <header><h1>Welcome to the Pie Shop</h1></header>
                    <img src="images/hero.jpg" width="100%" alt="A delicious blueberry pie" />
                    <h2>Our history</h2>
                    <p>Store narrative content goes here...</p>
                </article>
                <section id="promos">
                    <h2>Pies of the week</h2>
                    <div class="pie-card">
                        <img src="images/products/fruitpies/apple-pie-small.jpg" style="width:100%">
                        <div class="pie-card-container">
                            <p class="pie-card-name">Apple pie</p>
                            <p class="pie-card-price">$12.95</p>
                        </div>
                    </div>
                </section>
            </main>
        </div>
        <footer>
            <address>Pie Shop - Bakery Street 555</address>
            <p>Contact us via <a href="mailto:info@pieshop.example">email</a></p>
        </footer>
    </div>
</body>
</html>

Demo: Creating a Site with a Cloud Provider (Azure App Service)

1. Sign up for a cloud account (e.g., a 30-day trial with an initial credit, or a pay-as-you-go subscription), completing identity verification (multi-factor authentication) and billing details.
2. From the cloud portal, choose to create a resource. Unlike fixed hosting plans, cloud providers let you provision any resource you want and bill based on actual usage.
3. Resource options include virtual machines, web apps, databases, function apps (server-side processing callable from mobile/web clients), static web apps, and logic apps (event-driven service integration).
4. Choose Web App (the PaaS offering) to create a new App Service:
   • Place it inside a resource group — a container used for security scoping and coordinated deployment/deletion.
   • Give the app a globally unique name; this becomes part of the default URL: <name>.azurewebsites.net.
   • Choose whether the app runs directly on the host or inside a container.
   • Select a runtime stack (ASP.NET, Java, Node.js, PHP, Python) — or use a custom container for anything else.
   • Choose the underlying OS — Linux or Windows (cross-platform runtimes like .NET support either).
   • Choose a region.
   • Select or create an App Service Plan, which defines the size/tier of the underlying virtual machines. Multiple app services can share one plan.
5. After creation, the new App Service exposes a default URL and a management blade with many configuration sections (covered further in the next module).

flowchart TB
    RG[Resource Group] --> ASP[App Service Plan sizing/tier]
    ASP --> WA[App Service Web App]
    WA --> Runtime[Runtime Stack: .NET / Java / Node / PHP / Python / Container]
    WA --> OS[OS: Linux or Windows]
    WA --> URL["Default URL: name.azurewebsites.net"]

Demo: Deploying a Website to Azure Using Zip Deploy

Inside the App Service resource, several deployment options are available under Deployment → Deployment Center:

• Continuous deployment from a code repository — GitHub, Bitbucket, local Git, Azure Repos, or any Git-compliant external repository.
• FTP/FTPS — the FTP server hostname, username, and password are listed under the “FTPS credentials” tab. Note: FTP Basic Auth Publishing must be explicitly enabled under the Configuration tab for this to work.
• Zip Deploy via the Kudu portal — a companion administrative site deployed alongside every App Service (accessible from Development Tools → Advanced Tools → Go), providing tools for managing the app and inspecting the underlying VM environment.

Steps for zip deploy:

1. Open the Kudu portal for the App Service.
2. Under the Tools menu, find the zip-deploy feature, which shows the currently deployed files (initially just the default placeholder page).
3. On the local machine, select all website files, compress them into a single .zip archive.
4. Drag the .zip file into the zip-deploy drop target in the browser.
5. Kudu uploads the archive, unzips its contents, and recycles the App Service to pick up the new files. Deployment logs show each step.
6. Refresh the app’s URL to confirm the new site is live.

flowchart LR
    Files[Local Website Files] --> Zip[Compress to .zip]
    Zip --> Kudu[Upload to Kudu Zip Deploy]
    Kudu --> Extract[Kudu extracts files]
    Extract --> Recycle[App Service recycles]
    Recycle --> Live[Site live at azurewebsites.net]

Zip deploy and FTP are just two of many ways to deploy to Azure App Service (others include CI/CD pipelines, container deployment, and Git-based deployment).

Module 2: Configuring Your Deployed Website

With a site deployed to a hosting provider, this module covers configuring a custom domain name, enabling HTTPS/SSL, and optimizing page performance.

Understanding Domain Names and DNS Registration

DNS (the Domain Name System) is what allows a URL typed into a browser to be resolved to the IP address of the hosting web server. To use your own custom domain name on the Web:

• You don’t actually purchase a domain name outright — you pay to reserve it for a period of time (typically 1–10 years) through a domain name registrar (e.g., GoDaddy).
• Registrars provide registration services on behalf of a domain name registry — the organization that manages a given top-level domain (e.g., .com, .net). The registrar pays the registry a fee (bundled into what you pay).
• Registrars notify you when your reservation is about to expire so you can renew it.
• Registrars often also provide DNS hosting (to map your domain to your web server’s IP address), but this isn’t mandatory — DNS management can be delegated elsewhere.
• The hosting provider and the domain registrar can be, but don’t have to be, the same company. When they are the same, domain cost is sometimes bundled into hosting fees (e.g., a free domain included with a prepaid hosting term).
• Domain registration records contact information in a public database queried via the WHOIS protocol. Registrars typically offer a paid privacy service to hide this information from public search.
• Domain names can be transferred between registrars (e.g., when switching hosting providers or consolidating domain management).
• The overall system is supervised by ICANN (the Internet Corporation for Assigned Names and Numbers), which operates the root DNS servers, develops policy, and introduces new top-level domains. Registrars pay ICANN an administration fee per registration.

flowchart TB
    You[You / Site Owner] -->|pays reservation fee| Registrar[Domain Name Registrar]
    Registrar -->|registers domain, pays fee| Registry[Domain Name Registry .com/.net/etc.]
    Registry -->|policy and oversight| ICANN[ICANN - root DNS + policy]
    Registrar -->|optional| DNSHosting[DNS Record Hosting]
    DNSHosting -->|A record| WebServer[Your Web Server IP]

Demo: Configuring a Custom Domain Name in GoDaddy

1. Search for and purchase an available domain name (e.g., example.com) directly through the registrar’s dashboard.
2. Choose a reservation term (1–10 years; longer terms are usually cheaper per year) and optionally decline/accept add-ons like domain privacy protection or bundled email.
3. After purchase, decline any prompt to auto-create a placeholder “coming soon” site if you intend to point the domain at an existing hosting plan instead.
4. From My Products → Web Hosting → Manage, choose to connect a domain, select the newly purchased domain, and confirm that it should replace any existing default domain association.
5. DNS propagation for the change can take up to an hour (sometimes longer) — this is normal and expected.
6. Under cPanel → Domains, you can also configure a Force HTTPS Redirect setting (requires an SSL certificate to be associated with the domain first — covered later in this module).
7. Once propagation completes, navigating to the custom domain shows the deployed website.

Demo: Configuring a Custom Domain Name in Azure

Unlike GoDaddy (registrar + host combined), Azure App Service typically points to a domain purchased elsewhere:

1. In the App Service, go to Custom domains. The default *.azurewebsites.net domain is listed. You can either buy an App Service Domain (Microsoft-managed, but actually registered through GoDaddy behind the scenes) or add a custom domain you already own.
2. Choose Add custom domain → All other domain services, then enter the domain name.
3. Two DNS records must be created with your DNS provider to point the domain at the App Service and to prove ownership:

4. Add these records through your DNS provider’s editor (any registrar/DNS host works — the demo uses a third-party DNS provider unrelated to Azure).
5. Back in Azure, click Validate. Azure checks public DNS (propagation-dependent) to confirm the records exist, then allows the App Service to accept traffic for that domain — preventing anyone else from pointing an arbitrary domain at your app.
6. Once validated, add the custom domain. Its status will show “No binding” until an SSL certificate is attached (see below) — until then, HTTPS will not work for the custom domain, and browsers will flag the site as insecure.

sequenceDiagram
    participant Owner as Domain Owner
    participant DNSProvider as DNS Provider
    participant Azure as Azure App Service

    Owner->>DNSProvider: Create A record (root -> App Service IP)
    Owner->>DNSProvider: Create TXT record (asuid -> verification token)
    Owner->>Azure: Click "Validate"
    Azure->>DNSProvider: Query public DNS for A/TXT records
    DNSProvider-->>Azure: Records found
    Azure-->>Owner: Domain validated, custom domain added (no SSL binding yet)

Understanding HTTPS, SSL, and TLS

SSL (Secure Sockets Layer) is the original technology for encrypting web traffic. It has since been deprecated and replaced by TLS (Transport Layer Security), which offers stronger and faster encryption — but “SSL” remains the commonly used term for the encryption behind HTTPS.

How it works, at a high level:

1. A certificate containing the domain name is installed on the web server. The certificate is issued by a trusted certificate authority (CA) that verifies the site belongs to the domain owner.
2. Certificates form a chain of trust — the issuing CA’s certificate is part of that chain, and browsers ship with copies of the trusted root CA public certificates.
3. Servers use public key infrastructure (PKI): the certificate has a public key (used by anyone to encrypt data sent to the server) and a private key (kept only on the server, used to decrypt).
4. When a browser connects over HTTPS, the server’s public key is exchanged, and the browser and server negotiate a unique session key for that connection. All subsequent traffic is encrypted with the session key.

sequenceDiagram
    participant Browser
    participant Server as Web Server (has private key)
    participant CA as Certificate Authority

    Server->>CA: Certificate issued for domain
    Browser->>Server: HTTPS connection request
    Server-->>Browser: Sends certificate (public key)
    Browser->>Browser: Validates certificate chain against trusted root CAs
    Browser->>Server: Negotiate session key
    Note over Browser,Server: All further traffic encrypted with session key

Benefits of HTTPS:

• Prevents data from being read or altered in transit (protects sensitive data such as payment details).
• The padlock icon and “https://” prefix increase user trust; most browsers explicitly flag non-HTTPS sites as “Not secure.”
• HTTPS usage is a search engine ranking factor (part of technical SEO, covered in Module 3).

SSL certificates are issued per domain. They can be purchased from a CA (or through your domain registrar), or many hosting providers (including GoDaddy and Azure App Service) offer free SSL certificates bundled with hosting.

Demo: Configuring SSL in GoDaddy

GoDaddy provides a free AutoSSL feature on certain paid plans:

2. AutoSSL periodically scans hosted domains and installs domain-validated certificates automatically — no manual purchase required.
3. The same screen lets you upload your own certificate if you manage one independently.
4. GoDaddy automatically redirects unencrypted requests on port 80 to the encrypted endpoint on port 443 at the web-server level. If you upload and manage your own certificate elsewhere, you may need to configure this redirect manually.
5. A Force HTTPS Redirect setting is also available under cPanel → Domains for explicit control.

Demo: Configuring SSL in Azure App Service

1. In the App Service, go to Certificates. Three certificate options are available:
   • Bring your own certificate — upload a .pfx file purchased from any certificate authority or domain registrar (some registrars sell standard or wildcard certificates; a wildcard certificate secures all subdomains of a domain, e.g., admin.example.com, ftp.example.com).
   • App Service–managed certificate — a free certificate issued and managed by the platform.
   • A third option for advanced/enterprise certificate management scenarios.
2. Choose Managed certificates → Add certificate, select the target domain, optionally rename the friendly name, then click Validate and Add. Provisioning can take up to ~10 minutes.
3. Once the certificate exists, go to Custom domains → Add binding, choose the certificate, then choose the SSL type:
   • SNI SSL (Server Name Indication) — allows multiple certificates to share one IP address; modern browsers support it by sending the requested hostname during the TLS handshake. This is the default and recommended choice.
   • IP-based SSL — dedicates a new IP address to the app (requiring a DNS A record update); only needed to support very old clients that don’t support SNI.
4. After binding, the custom domain automatically redirects HTTP to HTTPS if the HTTPS Only setting is enabled under Configuration.

flowchart LR
    A[Choose Certificate Source] --> B{Bring your own or App Service managed?}
    B -->|Own PFX| C[Upload certificate]
    B -->|Managed| D[Validate + Add managed certificate]
    C --> E[Add TLS/SSL binding]
    D --> E
    E --> F{SNI SSL or IP SSL?}
    F -->|SNI - default| G[Shared IP, hostname-based routing]
    F -->|IP-based| H[Dedicated IP, update DNS A record]
    G --> I[HTTPS Only redirect enabled]
    H --> I

Performance Optimization Fundamentals

Page load speed is both a user-experience factor and a technical SEO ranking factor — especially for mobile searches.

Two free tools for measuring performance:

Key Core Web Vitals metrics reported by both tools:

General techniques to improve page load performance:

• Compression — enabling gzip (or similar) compression for text-based assets (HTML, CSS, JavaScript) so they download as a smaller package and are unzipped by the browser. This may be configurable in a hosting configuration file or handled automatically by a CDN.
• Content Delivery Network (CDN) — caches your site on edge servers around the world so it’s served from the location closest to each visitor. Available from AWS, Azure, GoDaddy, and dedicated CDN vendors; Azure CDN integrates with App Service and can optimize both static and dynamic content.
• Browser caching — using Cache-Control HTTP response headers so returning visitors load CSS/JS/images from their local cache instead of re-downloading them.
• Other techniques: inlining critical CSS, minimizing third-party scripts, and minifying code (reduces character count for faster transfer, at the cost of readability).
• Image and video optimization (often the biggest opportunity):
  • Don’t rely on HTML width/height attributes alone to “resize” an oversized image — the full file is still downloaded regardless of its displayed size.
  • Serve different image resolutions depending on device type (e.g., smaller images for mobile) using responsive CSS/HTML techniques.
  • Use modern, more efficient image formats such as WebP instead of traditional JPEG/PNG where supported.
  • Use loading="lazy" on <img> tags so images below the fold don’t block initial page rendering — though this is a mitigation, not a substitute for properly sizing/compressing images in the first place.
  • Compress images to reduce file size while preserving acceptable visual quality — usually the highest-impact, lowest-effort optimization.

flowchart TB
    User[User Request] --> CDN{CDN Edge Cache?}
    CDN -->|Cache hit| Edge[Serve from nearest edge server]
    CDN -->|Cache miss| Origin[Fetch from origin web server]
    Origin --> CDN
    Edge --> Browser[Browser]
    Browser --> LocalCache{Browser cache valid? Cache-Control headers}
    LocalCache -->|Yes| Local[Load asset from local cache]
    LocalCache -->|No| CDN

Illustrative examples of responsive image techniques discussed conceptually in this module:

<!-- Serve different image resolutions/formats depending on device using <picture> -->
<picture>
  <source media="(max-width: 600px)" srcset="images/hero-mobile.webp" type="image/webp">
  <source media="(min-width: 601px)" srcset="images/hero-desktop.webp" type="image/webp">
  <img src="images/hero.jpg" alt="A delicious blueberry pie" loading="lazy" width="1200" height="600">
</picture>

/* Responsive image sizing via CSS media queries */
.hero-image {
  width: 100%;
  height: auto;
}

@media (max-width: 600px) {
  .hero-image {
    content: url("images/hero-mobile.jpg");
  }
}

Demo: Using DevTools/Lighthouse to Measure Page Load

1. Open DevTools (F12) in Chrome or Edge and select the Lighthouse tab.
2. Leave the default categories selected (Performance, Accessibility, Best Practices, SEO).
3. Run the analysis once with mobile device simulation (throttled bandwidth) to establish a worst-case baseline, and once with Desktop settings for comparison.
4. Review the Performance score and Metrics section (e.g., Largest Contentful Paint).
5. Review actionable recommendations, such as:
   • Serve images in next-gen formats (e.g., WebP) with an estimated bandwidth savings.
   • Properly size images — oversized source files (e.g., a multi-megabyte hero image) are flagged as a major opportunity.
   • Add explicit width/height attributes and a caching policy.
6. Review Accessibility audits (e.g., missing alt attributes on images, color contrast issues, missing lang attribute) and Best Practices audits.
7. Use the Elements panel’s inspect/hover tool to identify exactly which <img> element on the page corresponds to a large flagged asset.

Example baseline results from this module’s demo site:

Demo: Resizing an Image and Retesting Performance

1. Connect via FTP to the remote site (using the site’s IP address if a dedicated FTP subdomain hasn’t propagated in DNS yet).
2. Navigate to the images folder and identify the oversized file — in this case, a hero image at 2.7 MB (an even larger 43 MB image existed in the folder but wasn’t referenced anywhere on the site and was safely ignored).
3. Use a free image-compression tool (e.g., a web-based service like ImageOptim) to compress the image without a significant visible quality loss — the file dropped from 2.7 MB to 274 KB.
4. Upload the compressed image back to the same path via FTP, overwriting the original.
5. Re-run the Lighthouse mobile test: performance score improved from 74 to 79, and Largest Contentful Paint improved from 18.2 seconds to 5.6 seconds.

This demonstrates that a single, well-targeted optimization (compressing one oversized image) can produce a significant performance improvement. Performance optimization is an ongoing, iterative process.

Module 3: Search Engine Optimization

With the site deployed, configured with a custom domain, protected by HTTPS, and reasonably performant, the final step is making it easy for users to find via search engines.

How Search Engines Work

There are roughly 1.1 billion websites on the Internet, though only about 200 million are actively maintained and visited. Over 362 million domain names are registered, and about 250,000 new websites are added each day. Google holds over 90% of search engine market share. When a user searches, the results page returned is called the SERP (Search Engine Results Page).

Getting a page returned in search results is a three-stage process:

flowchart LR
    A[Crawling] --> B[Indexing]
    B --> C[Ranking / Serving Results]
    A1[Web crawlers/bots/spiders discover pages via links or a submitted sitemap] -.-> A
    B1[Google analyzes text, titles, meta tags, alt attributes, language, locality signals] -.-> B
    C1[User query matched against index using hundreds of ranking signals] -.-> C

1. Crawling — automated web crawlers (“bots,” “robots,” “spiders”) continuously explore the web, downloading text, images, and video. Most pages are discovered automatically by following links from existing pages. Site owners can accelerate/control this by submitting a sitemap.
2. Indexing — after crawling a page, the search engine analyzes what the page is about, using visible text as well as invisible signals: the <title> element, meta tags, and alt attributes on images/video. These alt attributes also matter for accessibility (screen readers). Signals such as page language and geographic relevance are collected too.
3. Ranking/serving — when a user submits a query, the engine searches its index for the highest-quality, most relevant pages using hundreds of undisclosed ranking factors. The exact algorithm isn’t public, and it’s continually refined to improve relevance and combat manipulation (“spam”). The practice of improving a site’s visibility in this process is called Search Engine Optimization (SEO).

Understanding Search Engine Optimization

SEO targets organic (unpaid) traffic — results ranked purely by relevance, as opposed to sponsored/paid placements at the top of a SERP. SEO breaks down into three categories:

mindmap
  root((SEO))
    On-Page SEO
      Relevant, useful content
      Title tag under 60 characters
      Meta description
      Keywords in H1/H2/body text
      Alt text for images/video
      Correct page type for search intent
      Structured data (JSON-LD)
    Off-Page SEO
      Backlinks from trusted sites
      Social media mentions
      Directory listings (Google Business, Yelp)
    Technical SEO
      HTTPS
      Page speed / Core Web Vitals
      Mobile-friendly responsive design
      Clean site architecture and short URLs
      Sitemap.xml and robots.txt

On-page SEO is about making pages relevant and useful enough to rank for target keywords (the terms users type into a search box):

• The single most important factor is genuinely relevant, useful content — there’s no substitute for content real users actually want; low-value content aimed only at manipulating rankings won’t work and can be penalized.
• Place target keywords naturally in the <title> tag (keep it under ~60 characters) and in at least one <h2> and the opening body text. Google’s own documentation states the meta description tag is not used for ranking, though it does affect how the page displays (and therefore click-through rate) on the SERP.
• Add alt text to images and video — this is also an accessibility best practice for screen reader users.
• Choose the page type that matches search intent (e.g., a list-style page for “best X” searches, a blog/review-style page for product comparisons).
• Add structured data (JSON-LD) so Google can classify content precisely and potentially render rich results.

Off-page SEO is about signaling relevance from outside your own site:

• Backlinks — links from other (ideally authoritative/trusted) sites act as a “vote of confidence.” Quality matters far more than quantity; buying backlinks can actually hurt rankings.
• Mentions in social media and listings in directories (e.g., Google Business, Yelp) send additional positive signals.
• Legitimate backlink strategies include creating link-worthy content, guest blogging, and asking sites that already mention your product (without a link) to add one.

Technical SEO focuses on site architecture, speed, security, and crawlability:

• Prioritizing HTTPS.
• Page speed (Core Web Vitals, covered in Module 2).
• Mobile-friendly, responsive design.
• Clean site architecture — pages reachable within a few clicks of the home page, and short, descriptive URLs (helps with breadcrumb navigation and bookmarking).
• sitemap.xml and robots.txt (covered next).

Spam Policies: What Not to Do

Google publishes detailed spam policies describing manipulative tactics that will cause a page to rank lower or be delisted entirely:

If a technique seems like it “games the system” without genuinely improving content, it’s worth checking whether it violates one of these policies — violations risk a page (or the whole site) being delisted from search results entirely.

Search Engine Crawlers, Sitemaps, and robots.txt

Two files placed at the root of a site help crawlers process it more effectively:

sitemap.xml — an XML file (schema defined by sitemaps.org, UTF-8 encoded) that tells crawlers which pages/files exist, their relative importance, and how frequently they change. It’s especially useful for:

• Large or new sites, or sites with few external links (Google might not discover every page just by following links).
• Sites with rich media (video/images) or content in Google News, since dedicated sitemap variants exist for images, video, and news.

Submitting a sitemap is only a hint to Google — it doesn’t guarantee crawling or indexing, but it’s still recommended practice.

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.com/</loc>
    <lastmod>2025-01-15</lastmod>
    <priority>1.0</priority>
  </url>
  <url>
    <loc>https://example.com/pieoverview.html</loc>
    <lastmod>2025-01-10</lastmod>
    <priority>0.8</priority>
  </url>
  <url>
    <loc>https://example.com/contact.html</loc>
    <lastmod>2025-01-05</lastmod>
    <priority>0.5</priority>
  </url>
</urlset>

robots.txt — a plain-text file that tells crawlers which URLs on the site they may access. It’s advisory: crawlers are expected to respect it, but Google explicitly notes there’s no guarantee a disallowed page won’t still be indexed unless it’s also excluded via a noindex meta tag or HTTP response header.

User-agent: *
Disallow: /admin/
Disallow: /cgi-bin/

Sitemap: https://example.com/sitemap.xml

Neither file is strictly required, but both are recommended to help search engines understand what to crawl, index, and how to prioritize it.

Demo: Creating a Sitemap.xml

For a small, flat site, a sitemap could be handwritten. For anything larger, use a generator tool:

1. Use a free sitemap generator (many tools exist; some offer a free tier up to a page-count limit, with paid tiers for larger/more complex sites — some site platforms also support installing a script that generates the sitemap directly on the server).
2. Enter the site’s URL and let the tool crawl the site automatically.
3. Preview the discovered pages to confirm nothing was missed.
4. Download the generated sitemap.xml. It contains a <urlset> wrapping individual <url> nodes, each with a <loc> (page URL), <lastmod> (last modified date), and <priority> (relative importance — the home page is typically prioritized highest; not every page should be 1.0).
5. Upload sitemap.xml to the domain root via FTP (the same workflow used earlier to deploy the site).

Demo: Submitting a Sitemap to Google Search Console

1. Open Google Search Console and add a new property for the domain. Two verification options are available:
   • Domain property — covers all subdomains and protocols (HTTP/HTTPS), verified by adding a DNS TXT record.
   • URL-prefix property — narrower in scope (a specific protocol/subdomain), verified via a file upload or an HTML meta tag instead of a DNS change.
2. For domain-level verification, copy the TXT record value provided by Search Console.
3. In the domain’s DNS management screen, add a new TXT record at the root (@) with that value, then save.
4. Back in Search Console, click Verify. If DNS hasn’t propagated yet, verification fails — wait and retry (propagation can take several minutes to longer).
5. Once verified, go to Sitemaps, enter the fully qualified sitemap URL (e.g., http://example.com/sitemap.xml), and click Submit.
6. The status may initially show “Couldn’t fetch” even though the file is reachable directly — this is expected until Google actually crawls the site, which doesn’t happen instantly (Search Console notes to check back after a day or so).

sequenceDiagram
    participant Owner
    participant GSC as Google Search Console
    participant DNS as DNS Provider
    participant Google as Google Crawler

    Owner->>GSC: Add property (Domain)
    GSC-->>Owner: TXT record value to add
    Owner->>DNS: Create TXT record with value
    Owner->>GSC: Click Verify
    GSC->>DNS: Query TXT record
    DNS-->>GSC: Record found
    GSC-->>Owner: Ownership verified
    Owner->>GSC: Submit sitemap.xml URL
    GSC-->>Owner: Sitemap submitted (status: pending crawl)
    Google->>Owner: Crawls site over subsequent days

Exploring the Google Search Console

Once a property has accumulated crawl/search data, Search Console provides:

A URL Inspection tool lets you check the current index status of any URL within the verified property, test a live fetch, request (re)crawling, and inspect detected structured data. Search Console is a key diagnostic tool for understanding how Google sees a site and for catching problems (like unexpected redirects or missing HTTPS) that might otherwise go unnoticed.

Keyword Targeting and Search Intent

Keyword targeting means identifying what your potential audience actually types into a search engine, then naturally incorporating those terms — and, more importantly, creating content around those queries (which may go beyond content you’d have otherwise written) to build topical authority and domain authority.

Keyword categories by search intent:

Exploring Keyword Research Tools

Three approaches to keyword discovery, from free to paid:

1. Google Search itself — search a candidate term (e.g., “online pie shop”) and review competitor titles/descriptions in the results, the “People also search for” section, and autocomplete suggestions as you type partial queries. This surfaces related terms and question-style (“People also ask”) ideas you might not have considered.
2. Google Keyword Planner (part of Google Ads) — requires a Google Ads account (and an active/funded campaign) but provides estimated monthly search volume ranges, quarter-over-quarter and year-over-year trend changes, and competition level for a seed keyword, plus a list of related keyword ideas.
3. Third-party SEO suites (e.g., Semrush, Ahrefs — commonly used, paid, with limited free tiers) — a Keyword Magic-style tool can return:
   • Intent classification (informational/navigational/commercial/transactional) for each keyword.
   • Volume — average monthly search volume over the last 12 months (typically more precise than Keyword Planner’s ranges).
   • Keyword difficulty — how hard it would be to rank in the top 10 for that term (higher = harder); useful for prioritizing attainable targets, especially for newer sites with lower domain authority.
   • Estimated cost-per-click advertisers are paying for the term.
   • SERP features likely to appear for that query (image packs, “People also ask,” product carousels via structured data, etc.) — filterable, so you can specifically target keywords that trigger rich results.
   • Top-ranking competitor pages for a given keyword (paid plans typically unlock deeper competitor/backlink data).

flowchart LR
    A[Seed keyword idea] --> B[Google Search autocomplete + related searches]
    A --> C[Google Keyword Planner - volume ranges, trends, competition]
    A --> D[SEO suite - Semrush/Ahrefs: intent, volume, difficulty, CPC, SERP features]
    B --> E[Prioritized keyword list]
    C --> E
    D --> E
    E --> F[Incorporate into titles, headings, body content, and new content ideas]

Structured Data for Rich Results

Structured data is markup that users don’t see directly on the rendered page but that search engines use to understand — and sometimes visually enhance — how a result is displayed (a “rich result”), such as ratings, review counts, price, and availability shown directly on the SERP.

Key points from the schema.org / Google structured data model:

• The recommended format is JSON-LD (JSON linked data), placed in a <script type="application/ld+json"> element in the page’s <head> (or <body>).
• Google supports structured data for many categories: articles, courses, events, FAQs, job postings, local businesses, recipes, vacation rentals, vehicle listings, and products (with subtypes for merchant listings).
• You don’t control the visual rendering of a rich result — that’s entirely up to the search engine. You only supply as complete and accurate a data set as possible.
• Structured data should be validated in two ways:
  1. schema.org’s Validator — confirms the markup is syntactically valid for the declared schema/type.
  2. Google’s Rich Results Test — confirms Google can actually parse it for rich results (schema-valid data can still be flagged as insufficient for a rich result, e.g., a missing required price field under an Offer).

Example JSON-LD structured data for a product page (from this module’s demo):

<script type="application/ld+json">
{
    "@context": "https://schema.org/",
    "@type": "Product",
    "name": "Apple Pie",
    "image": [
        "https://example.com/images/products/fruitpies/apple-pie.jpg"
    ],
    "description": "An all-American traditional apple pie, available for online order anywhere in the world!",
    "sku": "013",
    "brand": {
        "@type": "Brand",
        "name": "Pie Shop"
    },
    "aggregateRating": {
        "@type": "AggregateRating",
        "ratingValue": 4.6,
        "reviewCount": 52
    },
    "offers": {
        "@type": "Offer",
        "url": "https://example.com/applepie.html",
        "availability": "https://schema.org/InStock",
        "price": 12.95,
        "priceCurrency": "USD",
        "priceValidUntil": "2025-12-31",
        "shippingDetails": {
            "@type": "OfferShippingDetails",
            "shippingRate": {
                "@type": "MonetaryAmount",
                "value": "5.00",
                "currency": "USD"
            },
            "deliveryTime": {
                "@type": "ShippingDeliveryTime",
                "handlingTime": {
                    "@type": "QuantitativeValue",
                    "minValue": 1,
                    "maxValue": 2,
                    "unitCode": "DAY"
                },
                "transitTime": {
                    "@type": "QuantitativeValue",
                    "minValue": 2,
                    "maxValue": 5,
                    "unitCode": "DAY"
                }
            },
            "shippingDestination": {
                "@type": "DefinedRegion",
                "addressCountry": "US"
            }
        },
        "hasMerchantReturnPolicy": {
            "@type": "MerchantReturnPolicy",
            "applicableCountry": "US",
            "returnPolicyCategory": "https://schema.org/MerchantReturnFiniteReturnWindow",
            "returnPolicySeasonalOverride": "false",
            "merchantReturnDays": 30,
            "returnMethod": "https://schema.org/ReturnByMail",
            "returnFees": "https://schema.org/FreeReturn"
        }
    }
}
</script>

Demo: Deploying and Testing Structured Data

1. Add the JSON-LD <script> block to the <head> of the target product page in a text editor.
2. While editing, also strengthen on-page SEO signals on the same page: make the <title> tag specific and descriptive (e.g., “Apple Pie” rather than a generic store title), and sync the meta description with the structured-data description (duplicating relevant text across both is reasonable, since it’s unclear which one a given search result will draw from).
3. Add any fields flagged as missing by the Rich Results Test (in this case, price/priceCurrency under offers), referencing schema.org’s documentation for correct placement.
4. Save the file and upload it via FTP to the deployed site, overwriting the previous version.
5. Re-run Google’s Rich Results Test against the live, deployed URL (not just the local snippet) using either the “smartphone” or “desktop” inspection type.
6. A valid result shows no errors/warnings and a preview of how the rich result might appear — e.g., title, availability, rating, and review count sourced from the structured data, while the description shown may be pulled from on-page text rather than the meta description or JSON-LD description. Google explicitly notes that this preview is only a simulation; actual SERP appearance is not guaranteed.

flowchart TB
    A[Add JSON-LD script to page head] --> B[Update title tag + meta description]
    B --> C[Fix missing required fields, e.g. price]
    C --> D[Validate with schema.org Validator]
    D --> E[Deploy updated page via FTP]
    E --> F[Test live URL with Google Rich Results Test]
    F -->|Valid| G[Eligible for rich result display - not guaranteed]
    F -->|Errors/Warnings| C

Summary

This course walked through the full lifecycle of getting a website live, configured, fast, and discoverable:

1. Foundations — the World Wide Web runs on top of the Internet using HTTP, built on TCP/IP, with DNS resolving domain names to IP addresses.
2. Hosting — websites live on web servers, either self-managed or (more commonly) rented from a traditional web host (shared hosting, simple and inexpensive) or a cloud provider using IaaS (full control, more responsibility) or PaaS (managed platform, easier operations, deep integration with other cloud services). Deployment methods include direct file upload, FTP, zip deploy, and CI/CD from a code repository.
3. Domain names — reserved (not “bought”) through a registrar for a fixed term, associated with a web server via DNS records (A records for IP addresses, TXT records for ownership verification), and governed globally by ICANN.
4. HTTPS/SSL/TLS — encrypts traffic between browser and server using certificate-based public key infrastructure; a ranking factor for SEO and essential for user trust. Free certificate options exist from most major hosts.
5. Performance optimization — measured with Lighthouse/PageSpeed Insights and Core Web Vitals (FCP, LCP, CLS); improved via compression, CDNs, browser caching, and — often highest-impact — image optimization (compression, modern formats, responsive sizing, lazy loading).
6. Search engine optimization — getting crawled, indexed, and ranked well through on-page SEO (content, keywords, structured data), off-page SEO (backlinks, mentions), and technical SEO (HTTPS, speed, mobile-friendliness, sitemaps/robots.txt) — all while avoiding spam-policy violations that can get a site penalized or delisted.

Quick-Reference Checklist

• Choose a hosting model (traditional shared hosting vs. IaaS vs. PaaS) that matches required runtime, control, and budget.

• Deploy the site (FTP, zip deploy, or CI/CD from a repository) and confirm the default document loads correctly.

• Register/point a custom domain name; create the required A/TXT DNS records; allow time for propagation.

• Enable a free or purchased SSL/TLS certificate; enforce HTTPS-only redirects.

• Run a Lighthouse/PageSpeed Insights baseline (mobile + desktop); target LCP under 2.5s and minimal CLS.

• Compress and properly size all images; consider modern formats (WebP) and lazy loading for below-the-fold media.

• Enable compression and configure browser/CDN caching for static assets.

• Add descriptive <title> tags (under ~60 characters), meta descriptions, and alt text across pages.

• Create and upload sitemap.xml and robots.txt at the site root.

• Verify the domain and submit the sitemap in Google Search Console; monitor Performance, Indexing, Core Web Vitals, and Security reports.

• Research keywords by intent (informational, navigational, commercial, transactional) and align content accordingly.

• Add JSON-LD structured data for eligible page types (e.g., products) and validate with schema.org and Google’s Rich Results Test.

• Review Google’s spam policies periodically to avoid unintentionally using manipulative tactics (cloaking, keyword stuffing, hidden text, link spam, scaled content abuse, site reputation abuse).

  Zip —> Kudu[Upload to Kudu Zip Deploy] Kudu —> Extract[Kudu extracts files] Extract —> Recycle[App Service recycles] Recycle —> Live[Site live at azurewebsites.net]

Zip deploy and FTP are just two of many ways to deploy to Azure App Service (others include CI/CD pipelines, container deployment, and Git-based deployment).

---

## Module 2: Configuring Your Deployed Website

With a site deployed to a hosting provider, this module covers configuring a custom domain name, enabling HTTPS/SSL, and optimizing page performance.

### Understanding Domain Names and DNS Registration

DNS (the Domain Name System) is what allows a URL typed into a browser to be resolved to the IP address of the hosting web server. To use your own custom domain name on the Web:

- You don't actually *purchase* a domain name outright — you pay to **reserve** it for a period of time (typically 1–10 years) through a **domain name registrar** (e.g., GoDaddy).
- Registrars provide registration services on behalf of a **domain name registry** — the organization that manages a given top-level domain (e.g., `.com`, `.net`). The registrar pays the registry a fee (bundled into what you pay).
- Registrars notify you when your reservation is about to expire so you can renew it.
- Registrars often also provide DNS hosting (to map your domain to your web server's IP address), but this isn't mandatory — DNS management can be delegated elsewhere.
- The hosting provider and the domain registrar can be, but don't have to be, the same company. When they are the same, domain cost is sometimes bundled into hosting fees (e.g., a free domain included with a prepaid hosting term).
- Domain registration records contact information in a public database queried via the **WHOIS** protocol. Registrars typically offer a paid **privacy service** to hide this information from public search.
- Domain names can be **transferred** between registrars (e.g., when switching hosting providers or consolidating domain management).
- The overall system is supervised by **ICANN** (the Internet Corporation for Assigned Names and Numbers), which operates the root DNS servers, develops policy, and introduces new top-level domains. Registrars pay ICANN an administration fee per registration.

```mermaid
flowchart TB
    You[You / Site Owner] -->|pays reservation fee| Registrar[Domain Name Registrar]
    Registrar -->|registers domain, pays fee| Registry[Domain Name Registry .com/.net/etc.]
    Registry -->|policy and oversight| ICANN[ICANN - root DNS + policy]
    Registrar -->|optional| DNSHosting[DNS Record Hosting]
    DNSHosting -->|A record| WebServer[Your Web Server IP]

Demo: Configuring a Custom Domain Name in GoDaddy

1. Search for and purchase an available domain name (e.g., example.com) directly through the registrar’s dashboard.
2. Choose a reservation term (1–10 years; longer terms are usually cheaper per year) and optionally decline/accept add-ons like domain privacy protection or bundled email.
3. After purchase, decline any prompt to auto-create a placeholder “coming soon” site if you intend to point the domain at an existing hosting plan instead.
4. From My Products → Web Hosting → Manage, choose to connect a domain, select the newly purchased domain, and confirm that it should replace any existing default domain association.
5. DNS propagation for the change can take up to an hour (sometimes longer) — this is normal and expected.
6. Under cPanel → Domains, you can also configure a Force HTTPS Redirect setting (requires an SSL certificate to be associated with the domain first — covered later in this module).
7. Once propagation completes, navigating to the custom domain shows the deployed website.

Demo: Configuring a Custom Domain Name in Azure

Unlike GoDaddy (registrar + host combined), Azure App Service typically points to a domain purchased elsewhere:

1. In the App Service, go to Custom domains. The default *.azurewebsites.net domain is listed. You can either buy an App Service Domain (Microsoft-managed, but actually registered through GoDaddy behind the scenes) or add a custom domain you already own.
2. Choose Add custom domain → All other domain services, then enter the domain name.
3. Two DNS records must be created with your DNS provider to point the domain at the App Service and to prove ownership:

4. Add these records through your DNS provider’s editor (any registrar/DNS host works — the demo uses a third-party DNS provider unrelated to Azure).
5. Back in Azure, click Validate. Azure checks public DNS (propagation-dependent) to confirm the records exist, then allows the App Service to accept traffic for that domain — preventing anyone else from pointing an arbitrary domain at your app.
6. Once validated, add the custom domain. Its status will show “No binding” until an SSL certificate is attached (see below) — until then, HTTPS will not work for the custom domain, and browsers will flag the site as insecure.

sequenceDiagram
    participant Owner as Domain Owner
    participant DNSProvider as DNS Provider
    participant Azure as Azure App Service

    Owner->>DNSProvider: Create A record (root -> App Service IP)
    Owner->>DNSProvider: Create TXT record (asuid -> verification token)
    Owner->>Azure: Click "Validate"
    Azure->>DNSProvider: Query public DNS for A/TXT records
    DNSProvider-->>Azure: Records found
    Azure-->>Owner: Domain validated, custom domain added (no SSL binding yet)

---

## Search Terms

`deploying` · `optimizing` · `websites` · `html` · `css` · `web` · `fundamentals` · `frontend` · `development` · `search` · `configuring` · `azure` · `godaddy` · `website` · `domain` · `engine` · `hosting` · `optimization` · `ssl` · `app` · `cloud` · `console` · `custom` · `data`