Post-Redirect-Get

The post / redirect / get pattern or PRG pattern is a development approach that prevents duplicate content when submitting forms and provides a more intuitive user interface. The post-redirect-get pattern allows you to set bookmarks, share URLs, and reload a website that queries and sends form data - without creating duplicate content or near duplicate content.

The PRG pattern is often used by large online shops to enable the limitation of products and product categories with faceted navigation and lessen the crawl budget. From the viewpoint of web design and search engine optimization, the PRG pattern is recommended to avoid duplicate content, provide split URLs, and conserve crawling resources. Implementation of this development approach requires knowledge of the post and get queries in the HTTP protocol version 1.1, and may require canonical tags and noindex markup.

General information

The reason for the use of the PRG pattern is as follows: When sending form data via an HTTP post request, this request can be submitted to the server several times if the user who submits the request reloads the form with the F5 or reload button. As a result, web forms or orders may end up getting submitted twice. The PRG pattern can be used to avoid this duplicate content. Instead of a website with duplicate content, the website which is delivered by means of a post-request and by a redirect is displayed.

How it works

When a client calls and fills in a web form, it is usually delivered to the server through a post request. The server makes a change to the database and enters the information from the web form there. Typically, the server will send a confirmation page back to the client. If there are errors or invalid entries, a web form will be displayed, which indicates these errors to the user. The user then corrects the data and clicks Send. The correct data gets sent to the server. If the user reloads the web form now, another undesirable data transfer of two entries will be created from the database.

This is where the PRG pattern comes in. After entry into the database, a redirect is sent to the client. The client then starts a get request to the server, which in turn sends a confirmation page. If the user happens to reload the website, only one other get request will be sent to the server. Instead of a database change with the post-request, the user will be shown the confirmation page. His request has already been fulfilled and the reloading of the web form does not lead to duplicate content.

The PRG pattern consists of two HTTP requests and a redirect that references the changed results. The pattern allows semantically correct processing of post and get requests in the HTTP 1.1 protocol:

• POST: A form is sent to the server with a post-request and an entry in the database is changed.
• Redirect: After a post request, the correct webpage with the changed data is delivered to the client using the redirect instruction (HTTP 303).
• GET: The client requests a confirmation page. When reloading, this is also done without a database change and possibly resultant duplicate content.

Practical relevance

In practice, the implementation of the PRG pattern is dependent on the programming language used on the server side and the content management system. A solution in PHP can look as follows: The web form is called echo.php, it must be generated and the processing server must support PHP parsing or use PHP as server-side language. In the example, the first loading of the file is triggered by a user who navigates to the website www.example.com/echo.php. The HTML in the file is displayed. The user then enters data and presses Enter. The entry is sent to the server as a database change and is delivered to the client through a get request. Even with another get request, the input remains current, as the modified content is retained by means of the session. The result is an HTML website that contains the entries but comes through a get request and does not create duplicate content because of another post request.

<?php
    session_start();

    $echoedShout = "";

    if(count($_POST) > 0) {
        $_SESSION['shout'] = $_POST['shout'];

        header("HTTP/1.1 303 See Other");
        header("Location: http://$_SERVER[HTTP_HOST]/echo.php");
        die();
    }
    else if (isset($_SESSION['shout'])){
        $echoedShout = $_SESSION['shout'];

        /*
            The source code which changes the database goes here.
        */

        session_unset();
        session_destroy();
    }
?>

<!DOCTYPE html>
<html>
<head><title>PRG pattern example in PHP</title>

<body>
    <?php echo "<p>$echoedShout</p>" ?>
    <form action="echo.php" method="POST">
        <input type="text" name="shout" value="" />
    </form>
</body>
</html>

Relevance to search engine optimization

The PRG pattern is recommended by web designers and SEOs in certain cases. In detail, the implementation depends on many different factors related to the server technology. CMS, server-side programming languages, ​​and different versions of PHP or ASP.NET can result in errors and complicate the implementation. Particularly in case of applications such as filter navigation, care should be taken as to which resources are displayed to users and search engines. In individual cases, canonical tags, noindex instructions, and SEO basics, such as speaking URLs, can be utilized for the flawless implementation of the PRG pattern. In the case of filter navigation, the crawl budget can also be controlled to a certain extent.

Web Links

• What is “post/redirect/get”
• PRG Pattern Video Tutorial