The article / redirect / get pattern or pattern PRG is a development approach that avoids content duplication 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 web portal that queries and submits form data, without creating duplicate or near-duplicate content.
The PRG pattern It is frequently used by large online stores to allow the limitation of products and product categories with faceted navigation and reduce the crawl budget. From a web design and SEO point of view, the PRG pattern to avoid duplication of content, provide split URLs, and conserve crawl resources. Implementing this development approach requires knowledge of the article and getting queries on version 1.1 of the HTTP protocol, and may require canonical tags and Noindex markup.
General information
The reason for using the PRG pattern is next: When form data is submitted using an HTTP mail request, this request can be sent to the server multiple times if the user submitting the request reloads the form with the F5 button or reloads. As a result, web forms or orders may end up being submitted twice. You can use the PRG pattern to avoid this duplicate content. Instead of a web portal with duplicate content, the web portal that is delivered via a post request and redirect is displayed.
How does it work
When a customer calls and fills out a web form, it is typically delivered to the server via a mail request. The server makes a change to the database and enters the information from the web form. Typically the server will send a confirmation page to the client. If there are errors or invalid entries, a web form will be displayed, indicating these errors to the user. The user then corrects the data and clicks Submit. The correct data is sent to the server. If the user reloads the web form now, another undesirable two-input data transfer will be created from the database.
This is where the PRG pattern. After entering the database, a redirect is sent to the client. The client then initiates a get request to the server, which in turn sends a confirmation page. If the user reloads the web portal, only another 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. Your request has already been fulfilled and reloading the web form does not result in duplication of content.
The PRG pattern these are two HTTP requests and a redirect that refers to the modified results. The pattern allows the semantically correct processing of messages and to 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 send request, the correct web page with the modified data is delivered to the client by means of the redirect instruction (HTTP 303).
- GET: The client requests a confirmation page. When reloaded, this is also done without a change to the database, and certainly without duplicating the resulting content.
Practical relevance
In practice, the implementation of the PRG pattern it depends on the programming language used on the server side and the content management system. A solution in PHP might look like the following: The web form is called echo.php, it must be caused and the rendering server must support PHP parsing or use PHP as the server-side language. In the example, the first upload of the file is launched by a user navigating to the web portal www.example.com/dated.php. The HTML of the file is displayed. The user enters the data and presses Enter. The input is sent to the server as a database change and delivered to the client via a get request. Even with another get request, the entry remains current, as the modified content is retained throughout the session. The result is an HTML web portal that contains the inputs but arrives via a get request and does not create duplicate content due to another publish 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="/en/echo.php/" method="POST" data-trp-original-action="echo.php">
<input type="text" name="shout" value="" />
<input type="hidden" name="trp-form-language" value="en"/></form>
</body>
</html>
[1]
Relevance for search engine optimization
The PRG pattern it 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 cause errors and complicate implementation. Particularly in the case of apps like filter browsing, care must be taken as to which resources are shown to users and search engines. In individual cases, canonical tags, noindex instructions, and SEO arguments, such as spoken URLs, can be used for flawless implementation of the PRG pattern. In the case of filter browsing, the crawl budget can also be controlled to some extent.
Web Links
