Hreflang XML sitemap generator
Build a sitemap with xhtml:link hreflang annotations for localized pages, with every alternate listed on every URL as Google's documentation requires.
Parse a meta refresh tag's delay and target, and see which redirect signal Google actually reads from it: permanent at 0 seconds, temporary above 0.
Runs entirely in your browser. Nothing you enter is uploaded, logged or stored.
Redirect method ranking
Google's documentation orders redirect methods "by how likely Google is able to interpret correctly": a server-side HTTP redirect (301 or 308 for permanent, 302, 303 or 307 for temporary) first, meta refresh second, a JavaScript location change third, and a crypto redirect last. Use a server-side redirect when you can set one; reach for meta refresh only when you cannot.
This tool parses the delay and target with a regular expression matched against the documentedcontent="<seconds>; url=<url>" syntax. It cannot see how your server responds, so it cannot check an actual HTTP redirect for you.
Paste a meta refresh tag or just its content value, and this tool tells you which of Google’s two redirect signal categories, permanent or temporary, it actually falls into. Everything runs against a regular expression matched to the documented syntax, in your browser only.
A meta refresh with a delay feels like the gentler option: give the visitor a moment before sending them along, rather than an instant, jarring server-side redirect. Google’s own documentation flips that intuition entirely. It groups “meta refresh (0 seconds)” alongside HTTP 301 and 308 under permanent redirects, stating the indexing pipeline treats it “as a signal that the redirect target should be canonical.” Any delay above 0 seconds moves the same tag into the temporary category instead, alongside HTTP 302, 303 and 307, where “the indexing pipeline doesn’t use the redirect as a signal that the redirect target should be canonical.” Adding a delay to be polite to visitors quietly tells Google the move might not be permanent, which can leave the old URL sitting in search results longer than intended.
The same documentation orders every redirect method “by how likely Google is able to interpret correctly.” Server-side HTTP redirects sit at the top of both the permanent and temporary lists, meta refresh sits second in each, a JavaScript location change third, and a crypto redirect last, with the explicit caution not to rely on it “unless you have no other choice.” None of this makes meta refresh invalid: it is a real, documented, supported method. It is simply a fallback for situations where a server-side redirect genuinely is not available, such as a static host with no server-side scripting, rather than a first choice on a stack that can set real HTTP status codes.
Build a sitemap with xhtml:link hreflang annotations for localized pages, with every alternate listed on every URL as Google's documentation requires.
Paste status codes and see how Google's crawlers document handling each one, plus a redirect hop count against Google's 10-hop default.
Audit the links in pasted HTML against Google's rel qualifiers: sponsored for paid links, ugc for user content and nofollow when neither applies.
Validate robots meta tags and X-Robots-Tag headers against the rules Google documents, and see the combined result for Googlebot.