PHP Only on the Front Page: Safer Checks for Live Sites

By Greg Nowak. Last updated 2026-11-07.

A campaign banner belongs on the homepage. A pricing teaser should disappear everywhere else. These sound like small website changes, until the banner vanishes for visitors arriving from a newsletter or appears on every page after deployment.

Use the application’s front-page or route API when one exists. On a small custom PHP site, compare explicitly allowed request paths. Then test the feature through the same links and caches your visitors use. The PHP entry point may still run across the site; the condition controls which code executes inside it.

Choose the check that fits your site

Before adding another condition to a shared header, check whether the feature can live directly in the homepage controller or template. That is often the easiest arrangement to maintain. Shared components need a condition when they genuinely serve several pages.

A plain PHP check with explicit boundaries

For a site where paths identify pages, separate the query string and compare the remaining path. Keep the deployment base path in configuration:

<?php
// APP_BASE_PATH: empty at the domain root; '/site' on staging.
$basePath = getenv('APP_BASE_PATH');
$homepagePath = '/' . trim($basePath === false ? '' : $basePath, '/');

$requestUri = $_SERVER['REQUEST_URI'] ?? null;
$path = is_string($requestUri)
    ? explode('?', $requestUri, 2)[0]
    : null;

$allowedPaths = $homepagePath === '/'
    ? ['/']
    : [$homepagePath, $homepagePath . '/'];

$isHomepage = in_array($path, $allowedPaths, true);

if ($isHomepage) {
    echo 'Only on the front page';
}

This expects a request URI beginning with a path such as / or /site/. Missing values and absolute URLs do not match. PHP documents that server variables depend on the web server, so confirm the value on your deployment.

At the domain root, both / and /?utm_source=newsletter match. With APP_BASE_PATH=/site, both /site and /site/ match. Repeated slashes and /index.php are deliberately excluded. If those are public aliases, decide whether to redirect them to the canonical homepage.

This simple split avoids using a general URL parser for a narrow path comparison. Existing code using parse_url() deserves review: the PHP manual warns about parsing inconsistencies and recommends standards-based URI classes for new URL-parsing code. Neither approach makes a homepage condition an access-control check.

If query parameters choose the page, such as /?page=services, this snippet is unsuitable. Use the same routing decision that selects the page; stripping those parameters would incorrectly classify other pages as home.

WordPress: front page and posts page are different

Use is_front_page() for the site’s main front page. It respects the configured static page or latest-posts setup. is_home() identifies the posts index, which can live on a separate blog page.

<?php
if (is_front_page()) {
    echo 'Only on the front page';
}

Place this in a theme template or an appropriate callback after the main query has run. Calling it immediately while loading a plugin or functions.php is too early. The WordPress function reference documents both the settings dependency and query timing.

Symfony and Laravel: use the matched route

Named routes keep shared logic readable when URL paths change. These examples assume the homepage routes are named homepage and home; replace those names with your application’s actual names.

In Symfony, once routing has run:

<?php
if ($request->attributes->get('_route') === 'homepage') {
    // Homepage-only logic
}

The Symfony routing documentation describes route information stored in request attributes. If the feature belongs solely to the homepage action, put it there instead of checking the route again.

In Laravel, after route matching:

<?php
if ($request->routeIs('home')) {
    // Homepage-only logic
}

Laravel’s request documentation confirms that routeIs() checks the matched named route. Avoid broad wildcard matches unless every matching route should receive the feature.

Test what visitors will actually receive

A successful preview is only part of the release check. Give the person approving the change a short acceptance list:

• Open the homepage directly and through a campaign URL with tracking parameters.
• Check two non-home pages, including one with parameters.
• Verify production and staging base paths, plus any language-specific homepages.
• Check logged-out and signed-in views, then repeat after the page cache is warm.
• Confirm the banner link, form submission, or integration works, rather than checking appearance alone.

A cached response may be served without running PHP again. If output varies by visitor, check that the cache configuration supports that variation. For campaign changes, include the relevant cache purge in deployment and rollback instructions.

Make the next change easier

Keep one clearly named homepage condition close to the component it controls. Record who owns the copy, when the feature ends, and how to disable it. Campaign dates and editor-managed content usually belong in configuration or CMS fields rather than another template condition.

If a small homepage change now involves several templates, plugins, and agency handovers, Greg can help clarify the rules and get the improvement released. See how Greg supports digital projects and ongoing website improvements.

Related on GrN.dk

• PHP Front-Page Detection: Safer Checks for Real-World Sites
• Debugging WordPress on a Live Site: A Safer Production Workflow
• Drupal Deployments: Keep Small Fixes From Rewriting Live Settings

Need help with this kind of work?

Discuss your website improvement with Greg Get in touch with Greg.

Sources

• PHP Manual: $_SERVER
• PHP Manual: parse_url
• WordPress Developer Reference: is_front_page()
• Symfony Documentation: Routing
• Laravel 13.x Documentation: HTTP Requests