URL Structure Best Practices for Search Engines

The Foundational Role of HTTPS in Modern URL Architecture

The protocol, specifically HTTPS (Hypertext Transfer Protocol Secure), is the absolute bedrock of any modern URL structure. Its presence is non-negotiable for any website serious about search engine optimization, user trust, and data security. Google officially confirmed HTTPS as a lightweight ranking signal in 2014, and its importance has only magnified since. A URL beginning with https:// immediately communicates to both users and search engine crawlers that the connection between the user’s browser and the web server is encrypted. This encryption protects against eavesdropping and man-in-the-middle attacks, ensuring that sensitive information like login credentials, personal data, and payment details cannot be easily intercepted.

Beyond the direct ranking boost, HTTPS profoundly impacts user behavior, which in turn influences SEO. Modern browsers like Chrome, Firefox, and Safari actively flag non-HTTPS sites as “Not Secure.” This prominent warning can dramatically increase bounce rates and decrease user engagement, both of which are negative signals to search engines. A user is far less likely to trust, engage with, or purchase from a site that their browser explicitly warns them against. Therefore, failing to implement HTTPS creates a significant trust deficit that can cripple conversion rates and overall site performance.

The migration from HTTP to HTTPS must be handled with meticulous care to avoid common SEO pitfalls. The most critical step is implementing site-wide 301 (permanent) redirects from all HTTP versions of URLs to their HTTPS counterparts. This ensures that any accumulated link equity and ranking power from the old URLs are transferred to the new, secure versions. Failure to do this can result in search engines seeing two separate versions of the site (HTTP and HTTPS), leading to severe duplicate content issues and a dilution of ranking signals.

Another common issue during migration is mixed content. This occurs when a secure HTTPS page attempts to load insecure HTTP resources, such as images, scripts, or stylesheets. Browsers will often block this insecure content or display a broken padlock icon, again eroding user trust and potentially breaking site functionality. A thorough site audit is necessary to identify and update all internal links and resource calls to use relative paths or explicit HTTPS URLs.

For maximum security and a clear signal to search engines, implementing HSTS (HTTP Strict Transport Security) is a crucial follow-up step. HSTS is a web security policy mechanism whereby a web server tells browsers that it should only be communicated with using HTTPS. This is enforced via an HTTP response header (Strict-Transport-Security). Once a browser receives this header, it will automatically convert all future attempts to access the site via HTTP to HTTPS, even before the request leaves the browser. This eliminates the need for the initial redirect on subsequent visits, improving speed and security.

Subdomains vs. Subfolders: A Critical Structural Decision

One of the most debated and consequential decisions in URL architecture is the choice between using subdomains (blog.example.com) and subfolders, also known as subdirectories (example.com/blog). This choice has significant and long-lasting implications for how search engines perceive your site’s structure, authority, and thematic relevance.

Historically, search engines often treated subdomains as separate entities from the root domain. This meant that the link equity and topical authority built on www.example.com did not fully or easily pass to blog.example.com. Each subdomain had to build its own authority from scratch. While Google has stated in recent years that their systems have become much better at understanding the relationship between a domain and its subdomains, the overwhelming consensus within the SEO community, supported by numerous case studies, is that subfolders are superior for consolidating SEO authority.

A subfolder is unequivocally seen by search engines as part of the same website as the root domain. All content placed within subfolders contributes directly to the overall authority and topical relevance of the main domain. When you publish a high-quality article on example.com/blog/expert-guide, the backlinks and authority it earns directly benefit example.com. This creates a powerful, unified site structure where every piece of content works to lift the entire domain’s ranking potential. Migrating content from a subdomain to a subfolder has, in many documented cases, resulted in a significant and immediate uplift in organic traffic because the authority is finally being consolidated into a single, powerful entity.

There are, however, specific and valid use cases for subdomains. These typically involve a clear and intentional separation of content or functionality.

1. Distinctly Different Business Lines: If a company has two completely separate arms that do not share an audience or topic, such as cloud.megacorp.com and consumer.megacorp.com, a subdomain makes logical sense.
2. Internationalization: Using a subdomain for a specific country, like de.example.com for Germany, can be a valid strategy, although it is often debated against the example.com/de/ subfolder approach. A subdomain can be useful if the international site needs to be hosted on a server in that specific country for performance reasons.
3. Staging or Development Environments: Using staging.example.com is a standard practice to test changes before pushing them to the live site. This should be blocked from indexing via robots.txt or password protection.
4. User-Generated Content or Separate Applications: Platforms like WordPress.com (username.wordpress.com) or services that provide a separate web application, like app.example.com, are prime candidates for subdomains to isolate the core marketing site from the functional application.

For the vast majority of websites, including blogs, e-commerce category pages, resource centers, and service pages, the subfolder approach is the optimal choice for maximizing SEO performance. It creates a simpler, more hierarchical structure that allows search engines to easily understand the relationships between different content sections and enables authority to flow freely throughout the entire site.

Crafting Human-Readable and Semantically Rich Slugs

The slug is the final part of the URL that identifies the specific page (e.g., in /blog/url-best-practices, the slug is url-best-practices). This is arguably the most important part of the URL for both users and search engines in terms of understanding the page’s content at a glance. A well-crafted slug is descriptive, concise, and keyword-rich.

Readability is Paramount: A user should be able to look at a URL pasted in an email or social media post and have a very good idea of what the page is about before clicking. This builds trust and improves click-through rates.

• Bad Example: example.com/cat1/p?id=5891_v2&ref=email
• Good Example: example.com/kitchen-appliances/blenders/high-speed-pro-blender

The good example is immediately understandable. It uses plain language and clearly shows the hierarchy of the content. Search engines are increasingly sophisticated and aim to understand content as a human would. A human-readable URL is also a search-engine-readable URL.

Strategic Use of Keywords: The URL slug is a prime location to include the page’s primary target keyword. While the ranking impact is not as strong as it once was, it remains a relevant signal for search engines. The keyword helps to reinforce the page’s topic, aligning with the page title, H1 tag, and body content. This alignment creates a strong, consistent signal of relevance.

• Page Topic: “Beginner’s Guide to Landscape Photography”
• Optimal Slug: /guides/beginners-guide-landscape-photography

It’s crucial to avoid keyword stuffing. The goal is not to cram every possible variation of a keyword into the slug. This looks spammy to users and search engines alike.

• Keyword Stuffed Example: /photo/photography/guide-landscape-photo-photographer-beginners-guide
• Good Example: /photography/guides/landscape-for-beginners

Word Separators: The Hyphen Reigns Supreme: The choice of word separator in a URL slug is not a matter of style; it is a technical best practice. Google has explicitly and consistently stated that hyphens (-) should be used to separate words. Search engines interpret hyphens as spaces, allowing them to parse the individual words in the slug correctly.

• .../blue-suede-shoes is read as “blue suede shoes.”

Underscores (_), conversely, are often interpreted by search engines as word joiners.

• .../blue_suede_shoes may be read as “bluesuedeshoes.”

This makes it much harder for the search engine to understand the individual concepts on the page. Using spaces (%20) is technically possible but highly discouraged. It creates ugly, difficult-to-read URLs when encoded and can cause issues with some systems and applications. Plus signs (+) are sometimes used, particularly in search query URLs, but for static page slugs, the hyphen is the undisputed industry standard.

Omitting Stop Words: Stop words are common words like “a,” “an,” “the,” “in,” “on,” and “of.” In many cases, these can be removed from the URL slug to make it shorter and more focused without losing its meaning.

• Page Title: “The Best Recipe for a Classic Lasagna”
• Potential Slug: /recipes/best-recipe-classic-lasagna

However, this is not a hard rule. Sometimes, removing a stop word can change the meaning or make the slug less natural. For example, in the slug /dell-vs-hp, the “vs” is critical to the meaning. In /star-wars-a-new-hope, removing the “a” would be awkward. The best practice is to use judgment: if the word is essential for clarity and readability, keep it. If it’s purely grammatical filler, remove it.

The Importance of a Consistent and Logical URL Structure

A website’s URL structure should mirror its information architecture. It should be logical, hierarchical, and predictable. This not only helps search engine crawlers understand the relationships between pages but also vastly improves user experience. When users can understand the site’s layout simply by looking at the URL, they can navigate more easily and feel more confident in where they are on the site.

A logical structure often follows the pattern of breadcrumbs: domain.com/category/subcategory/product-or-page.

• E-commerce Example: mystore.com/mens-footwear/running-shoes/trail-runner-model-x
• Blog Example: myblog.com/marketing/seo/link-building-strategies

This structure clearly communicates context. The link-building-strategies page is not just about any link building; it’s specifically within the context of SEO, which itself is a sub-topic of marketing. This siloed structure helps search engines recognize your site as an authority on specific topics. By grouping related content under a common subfolder, you create thematic clusters that reinforce your expertise in that area.

A key part of maintaining a logical structure is avoiding changes whenever possible. URLs should be considered permanent addresses. Changing a URL is equivalent to moving a physical store without telling anyone. All the brand recognition, customer familiarity, and, in SEO terms, link equity associated with that address are lost unless a proper forwarding notice (a 301 redirect) is put in place. Therefore, it’s crucial to design a “future-proof” URL structure from the outset.

Future-proofing involves avoiding elements that are likely to change. For example, do not include dates in the URLs of evergreen content. A slug like /blog/2023/10/best-seo-tools immediately dates the content. When 2024 rolls around, the URL makes the content seem old, even if you’ve updated the article itself. A user is less likely to click on a search result with a year-old date in the URL. A much better approach is a timeless slug like /blog/reviews/best-seo-tools. This allows you to update the content year after year without needing to change the URL and implement a redirect. The only time dates are appropriate in a URL is for content that is intrinsically tied to that date, such as a news report or an event announcement.

Similarly, avoid overly specific technical jargon or version numbers in URLs if they are likely to be updated. A URL like /guides/using-photoshop-cs6 becomes obsolete when Photoshop CC is released. A more future-proof URL would be /guides/using-photoshop.

Managing URL Parameters for SEO

URL parameters (also known as query strings) are the part of a URL that follows a question mark (?). They are commonly used for tracking, sorting, filtering, or identifying sessions. While incredibly useful for analytics and user experience, they can be devastating for SEO if not managed correctly. The primary danger of URL parameters is the creation of massive amounts of duplicate content.

Consider an e-commerce category page for “shirts”: example.com/apparel/shirts. A user might use on-site filters to refine their view. This can generate numerous new URLs:

• .../shirts?color=blue
• .../shirts?size=large
• .../shirts?sort=price-high-to-low
• .../shirts?color=blue&size=large&sort=price-high-to-low

In all these cases, the core content (the list of shirts) is largely the same, but for a search engine, these are four distinct URLs. If a search engine crawls and indexes all of these variations, it dilutes the ranking signals for the main category page and wastes valuable crawl budget on redundant pages. The search engine may even become confused about which version is the “main” one to rank.

There are several essential tools and techniques for managing URL parameters effectively.

1. The rel="canonical" Tag: This is the most important and effective tool. The canonical tag is a piece of HTML code placed in the of a webpage that tells search engines which version of a URL is the master or “canonical” version. For all the parameter-based URLs above, the canonical tag should point back to the clean, main category page.

On the page .../shirts?color=blue, the HTML should contain:

This tells Google, “Yes, you’ve found this URL with a color filter, but the content is essentially the same as the main shirts page. Please consolidate all ranking signals (like links) to that main URL and show that one in search results.” Implementing self-referencing canonicals on the main pages (e.g., the .../shirts page canonicalizing to itself) is also a best practice to prevent any unforeseen duplication issues.

2. robots.txt Disallow (Use with Extreme Caution): The robots.txt file can be used to prevent search engine crawlers from accessing certain URLs or directories. You could add a directive like Disallow: /*?* to block all URLs containing a question mark. However, this is a very blunt and often dangerous instrument. Blocking crawling means search engines cannot see the pages at all. If those filtered pages have acquired any external links, the equity from those links will be lost completely because the crawler can’t pass through the blocked page to see the canonical tag. A better approach might be to block specific, problematic parameters while allowing others that might generate valuable pages you do want indexed. In most modern SEO strategies, using rel="canonical" is strongly preferred over robots.txt disallow for managing parameter duplication.

3. Google Search Console’s (Deprecated) URL Parameters Tool: For many years, Google Search Console offered a tool that allowed webmasters to specify how Googlebot should handle certain parameters (e.g., “ignore this parameter,” “this parameter paginates”). However, Google officially deprecated this tool in 2022, stating that their crawlers have become much more effective at automatically understanding parameter behavior. The official guidance now is to rely on proper site signals like rel="canonical" and a logical site structure, and to let Google’s crawlers do their job. While the tool is gone, its existence underscored the importance of this issue.

A special and important category of parameters is UTM (Urchin Tracking Module) parameters, used for campaign tracking (e.g., ?utm_source=newsletter&utm_medium=email). These are purely for analytics and create classic duplicate content. These URLs must always have a canonical tag pointing back to the clean URL without the UTM parameters. Most well-configured websites and analytics platforms handle this automatically, but it’s crucial to verify.

Canonicalization: Consolidating Your URL Signals

Canonicalization is the process of selecting the single best URL from a set of duplicate or near-duplicate pages. It’s a broader concept than just managing parameters; it addresses all forms of URL duplication that can fragment your SEO authority. A robust canonicalization strategy is essential for ensuring that 100% of your ranking power is focused on a single, authoritative URL for each piece of content.

Common canonicalization issues include:

• WWW vs. Non-WWW: Search engines see https://www.example.com and https://example.com as two different websites. You must choose one as your preferred version and use 301 redirects to send all traffic and signals from the non-preferred version to the preferred one. This choice is a matter of preference and has no inherent SEO advantage, but consistency is mandatory.
• HTTP vs. HTTPS: As discussed, all HTTP traffic must be 301-redirected to the HTTPS version of your site. This is a critical canonicalization signal.
• Trailing Slash vs. Non-Trailing Slash: A server can often serve the same content at example.com/about/ (with a trailing slash) and example.com/about (without). Similar to the WWW issue, you must choose one format and 301-redirect the other to it. Most commonly, trailing slashes are used for directories (like /about/) and are omitted for files (like /about.html). Consistency across the entire site is the goal.
• Case Sensitivity: URL paths on many servers (especially Linux/UNIX-based) are case-sensitive. This means /PAGE and /page can be two different URLs. It is a universal best practice to enforce a single, lowercase URL structure. All uppercase or mixed-case URLs should be 301-redirected to their lowercase counterparts to prevent confusion and duplicate content. This also improves user experience, as users do not expect URLs to be case-sensitive.
• Index Files: Often, the homepage can be accessed via example.com, example.com/index.html, or example.com/index.php. All variations that include the index file should be 301-redirected to the clean root domain (example.com).

The primary tool for managing on-page canonicalization is the rel="canonical" tag. However, 301 redirects are the correct solution for site-wide issues like WWW vs. non-WWW or HTTP vs. HTTPS. A 301 redirect actively moves the user and the search engine bot to the correct URL, while a canonical tag is a suggestion that the bot encounters only after crawling the duplicate page. For consolidating signals across an entire domain structure, 301s are more powerful and direct.

URL Architecture for Pagination

Pagination, the process of dividing a large set of content (like blog posts or products) into multiple pages, presents a unique challenge for URL structure and SEO. If handled improperly, it can lead to duplicate content issues, a poor crawl experience, and a dilution of ranking signals.

Historically, the best practice for pagination was to use rel="next" and rel="prev" link attributes in the of the paginated series. This would signal the relationship between the pages to Google (e.g., Page 2 is the next part of Page 1). However, in 2019, Google announced that they had not actually used these attributes as an indexing signal for several years. This announcement shifted the best practices for handling pagination.

The current best practices for SEO-friendly pagination URLs are:

1. Create Unique, Crawlable URLs: Each page in a paginated series must have its own unique URL that can be crawled. This is typically done with a parameter, such as example.com/category?page=2, example.com/category?p=3, or a static-looking path like example.com/category/page/4. The links between these pages must be standard links that crawlers can follow. Do not hide pagination links behind JavaScript that doesn’t generate a proper href attribute.

2. Use Self-Referencing Canonical Tags: This is the most crucial element. Each page in the series should have a rel="canonical" tag that points to itself.

   • On .../category?page=2, the canonical should be .
   • On .../category?page=3, the canonical should be .

   This prevents the common mistake of canonicalizing all paginated pages (2, 3, 4, etc.) to the first page of the series. Doing so tells Google to ignore the content on pages 2, 3, and 4, which means any products or articles listed exclusively on those pages will never be indexed. By having each page canonicalize to itself, you are telling search engines that each paginated page is a unique piece of a larger whole and that its content is valuable and should be indexed.

3. Manage Title Tags and Headings: To avoid the appearance of thin or duplicate content, slightly modify the title tags and H1 headings for each paginated page. For example:

   • Page 1 Title: “Men’s Running Shoes | MyStore”
   • Page 2 Title: “Men’s Running Shoes – Page 2 | MyStore”
   • Page 3 Title: “Men’s Running Shoes – Page 3 | MyStore”

4. The “View All” Page Strategy: An alternative approach, suitable for smaller sets of items, is to create a “View All” page that displays all products or articles on a single URL. You can then add a rel="canonical" tag to all the individual paginated pages (Page 1, 2, 3…) that points to the “View All” page. This consolidates all link equity to a single, powerful page. However, this strategy must be used with caution. If the “View All” page becomes too large, it can suffer from extremely slow page load times, which is a negative ranking factor and provides a poor user experience. This strategy is only viable if the complete page loads quickly.

5. Infinite Scroll and SEO: Infinite scroll, where new content loads automatically as the user scrolls down, is a popular UX pattern but can be an SEO nightmare if not implemented correctly. The problem is that without proper configuration, there is only one URL (example.com/category), and the crawler cannot “scroll” to discover the additional content. The correct implementation involves using the History API (pushState) to change the URL in the browser’s address bar as the user scrolls into a new “page” of content. For example, as the user scrolls past the first 20 items, the URL should update to example.com/category?page=2. This ensures that each section of content has a unique, linkable, and crawlable URL, which can then be treated with the self-referencing canonical strategy described above.

Internationalization and URL Structure (hreflang)

For websites that target audiences in multiple countries or languages, the URL structure is the primary mechanism for signaling this targeting to search engines. A well-planned international URL structure, combined with the correct use of hreflang attributes, is critical for ensuring the right version of your site is shown to the right users in search results.

There are three primary URL structures for internationalization, each with its own pros and cons:

1. Country-Code Top-Level Domains (ccTLDs): This involves using a separate domain for each country, such as example.de for Germany, example.fr for France, and example.jp for Japan.

   • Pros: This is the strongest possible signal to both users and search engines that the site is specifically targeted to that country. It provides clear geotargeting and inspires user trust.
   • Cons: ccTLDs are expensive and complex to manage. Each domain is a separate entity and must build its own SEO authority from the ground up, as authority is not easily shared between them. It is the most resource-intensive option.

2. Subfolders with a Generic Top-Level Domain (gTLD): This involves using subfolders to denote the target language or country on a single gTLD, such as .com, .org, or .net. Examples include example.com/de/ for Germany and example.com/fr/ for France.

   • Pros: This is the most commonly recommended approach for most businesses. It is relatively easy to set up and manage. Most importantly, it consolidates all SEO authority onto a single root domain (example.com). Backlinks to the /de/ version help the authority of the entire example.com domain, and vice versa.
   • Cons: The user signal for geotargeting is slightly less obvious than a ccTLD.

3. Subdomains with a gTLD: This uses subdomains to specify the target location, such as de.example.com and fr.example.com.

   • Pros: It provides a clear separation of sites and allows for different server hosting locations, which can improve site speed for international users.
   • Cons: As with the general subdomain vs. subfolder debate, it can dilute SEO authority. While Google is better at associating them, the subfolder approach is generally considered safer for consolidating ranking power.

Regardless of the chosen URL structure, the hreflang attribute is essential. hreflang is an HTML attribute that tells Google which language and, optionally, which region a page is targeting. It must be implemented correctly across all alternate versions of a page.

For a page targeting English speakers in the United States and German speakers in Germany, the implementation would be:

On the https://example.com/us/page.html page, you would include:

On the https://example.com/de/page.html page, you would include:

The annotations must be reciprocal; each page must reference itself and all of its international alternates. It is also a best practice to include an hreflang="x-default" tag, which specifies the fallback page for users whose language or region does not match any of the specified versions. hreflang tags can be implemented in the HTML , in the HTTP header, or, most scalably, within an XML sitemap.

Common hreflang mistakes that can negate its effectiveness include using incorrect language or country codes (it must be ISO 639-1 for language and ISO 3166-1 Alpha 2 for country), using relative URLs instead of absolute URLs, and failing to include the reciprocal links.

The Nuances of URL Length and Click Depth

While modern browsers can handle extremely long URLs (often over 2,000 characters), and search engines can process them, there are strong SEO and usability reasons to keep URLs as short and concise as possible.

Usability: Short URLs are easier for users to read, copy and paste, share on social media, and remember. A long, complex URL with multiple parameters is intimidating and looks untrustworthy. In search results, a short, clean, descriptive URL is more likely to earn a click than a long, messy one.

SEO: While not a major ranking factor, there is a slight correlation between shorter URLs and higher rankings. This is likely indirect. Shorter URLs tend to be more focused, have a better keyword-to-noise ratio, and are more shareable, which can lead to more backlinks. A long URL can also be truncated in the search engine results pages (SERPs), hiding important keywords and context from the user. The goal should be to make the URL as short as it can be while remaining descriptive.

Click Depth and URL Structure: Click depth refers to the number of clicks required to get from the homepage to a specific page. This is often, but not always, reflected in the URL structure. A page at example.com/category/subcategory/item is likely at a click depth of 3.

Search engines use click depth as a proxy for a page’s importance. Pages that are closer to the homepage (lower click depth) are generally considered more important and are often crawled more frequently. Important, high-value pages should be accessible within a few clicks from the homepage. A deep, convoluted structure can cause “orphan pages”—pages that are so far from the main site architecture that search engine crawlers struggle to find and index them. This also means that link equity from the powerful homepage has a harder time flowing down to these deep pages.

A flat site architecture, where most pages are only two or three clicks from the home page, is generally preferable for SEO. This ensures that crawlers can easily discover all content and that authority is distributed more effectively throughout the site. The URL structure should reflect this by avoiding excessively nested subfolders, such as .../folder1/folder2/folder3/folder4/page. Such a structure signals to search engines that the page is of very low importance.

Handling URL Changes and Redirects

Even with a perfectly planned, future-proof URL structure, there will be times when URLs need to change. A site migration, a rebranding, or a content consolidation project might necessitate changing large numbers of URLs. How these changes are handled is absolutely critical to preserving SEO performance.

The 301 (Permanent) Redirect is the primary tool for this task. A 301 redirect tells both browsers and search engines that a page has permanently moved to a new location. When a search engine encounters a 301 redirect, it passes the vast majority (generally considered to be 90-99%) of the old URL’s link equity and ranking power to the new URL. This is essential for maintaining your search rankings after a URL change.

The process must be meticulous. Every old URL must be mapped to its most relevant new URL on a one-to-one basis. A common and disastrous mistake is to redirect all old pages to the new homepage. This is seen by Google as a soft 404 (page not found) error, and all the specific authority of the old pages will be lost. If an old page .../old-product is being retired, it should be redirected to the new replacement product, a relevant category page, or, if no relevant page exists, a custom 410 (Gone) page. A 410 status code explicitly tells search engines that the page has been intentionally removed and will not be coming back, which can help speed up its removal from the index more quickly than a 404 (Not Found).

Redirect chains—where URL A redirects to URL B, which then redirects to URL C—should be avoided. Each “hop” in a redirect chain can cause a slight loss of link equity and adds to page load time. All redirects should point directly from the original URL to the final destination URL.

The Role of URLs in XML Sitemaps

An XML sitemap is a file that lists all the important URLs on a website, providing a roadmap for search engines to help them discover and crawl your content more intelligently. While a strong internal linking structure is the primary way search engines find your pages, a sitemap is an essential supplement, especially for large websites, new websites with few external links, or sites with complex structures or deep pages.

The URLs included in your sitemap send a powerful signal to search engines about which pages you consider to be high-quality and worthy of indexing. The sitemap should only contain your canonical URLs. Including non-canonical URLs, redirected URLs, or pages blocked by robots.txt sends conflicting signals and can confuse crawlers.

Your sitemap must be kept clean and up-to-date. It should be dynamically generated to automatically include new pages as they are published and remove pages that have been deleted (or to update their location if they have been redirected). Submitting a sitemap that contains 404 errors or points to redirected URLs signals poor site maintenance to search engines.

For very large sites, a sitemap index file can be used. This is a sitemap that points to other sitemaps. This allows you to break up your URLs into logical groups (e.g., a sitemap for product pages, one for blog posts, one for category pages) and helps you stay under the 50,000 URL limit for a single sitemap file.

In addition to the URL itself (), the sitemap protocol allows for other tags, such as (last modification date), (how frequently the page is likely to change), and . While Google has stated they largely ignore and because webmasters often misuse them, the tag can be a useful hint. If Googlebot sees a recent modification date for a URL it has already crawled, it may be encouraged to recrawl it sooner to index the fresh content. As with all things, this information must be accurate. Providing a false date is a form of spam that can erode trust with search engines. For international sites, the XML sitemap is also the most efficient place to declare hreflang annotations, as it keeps all the international relationships for every URL in a single, manageable file.