Please help me fix this issue because it clearly seem that the issue is Litespeed cache related.

People who have problems should check if there are any other plugins that affect the htaccess file. This plugin takes care of the htaccess file.

Talking about the plugin, the developer did a good job. All http header codes and descriptions are available.

Respects!

We ran a Semrush Site Audit yesterday and it found 180 pages that were blocked by X-Robots-Tag: noindex HTTP header. Double checking in Google Search Console confirmed the pages were not indexed (Excluded by ‘noindex’ tag) and even the Request Indexing and Test Live URL both failed in Google Search Console.

Is there a way to resolve this with Seopress so that all pages are indexed (except for ones that have the Advanced meta robot setting “Do not display this page in search engine results / XML – HTML sitemaps (noindex)” checked)?

Thank you,

Adam

Hey, I am having the same issue as this person with the google search console for my sitemap.
I don’t seem to have the ‘noindex’ meta tag anywhere that I could find. It seems that all the robot files and meta tags are correct as well. But maybe I am wrong.
How would we fix this issue? Should we go to google to try and ask them if you dont see any problems on your end?

I have a main domain with LiteSpeed and it’s supported and the HTTP Header says: x-litespeed-cache: hit

But on my subdomain with the same settings not:x-litespeed-cache-control: no-cache

This is the report number from my subdomain where it does not work: SBMSDUSL

I checked this via “https://check.lscache.io/”

Can someone help me with this, please?

Best regards

Date Options
When replacing the media, do you want to:
( ) Replace the date
(?) Keep the date (18/Aug/2021 23:38)
( ) Set a Custom Date

I wish the description and/or the FAQ would have addressed what consequences these options have. Meanwhile I found out myself by trial and error:

“Keep the date” is the default. This can have bad consequences with browser caching! I am not talking about server caching or CDN here. This should specifically also be addressed in FAQ “I replaced a file, but it didn’t change!”.

Environment
– macOS 11.4 Big Sur
– Safari 14.1.1

Reproduction I
1) Replace media with “Keep the date”.
2) In normal view mode, access a page which embeds that media, via the menu.
3) The browser shows the old outdated image.
I assume because the HTTP timestamp header for the image file is unchanged (an eTag based on content hashing or comparing the HTTP size header should make clear that the file has indeed changed).
4) A forced page reload then shows the new image. This is insufficient as returning visitors with a browser cache should not get outdated imagery but also the newest like fresh visitors.

Reproduction II
1) Replace media with “Replace the date”. (sets it to now)
2) In normal view mode, access a page which embeds that media, via the menu.
3) The browser immediately shows the updated image.

Feature Improvement for “Set a Custom Date”
– “Set a Custom Date” by default copies “now” into the field.
– This is not a good init value as it’s redundant to option 1 “Replace the date”.
– I propose the following:

(?) Set a Custom Date
[__________] [__] [__] Now | Original

– The fields get initializing with the original timestamp.
– Clicking the “Now” or “Original” action link/button update the date/time fields accordingly.

I have a website in two language versions. For each of them I have a separate domain .pl (Polish language version) and .eu (English version). The .pl domain has an SSL certificate, and the .eu domain does not.

When I change the language being in the language version of a page with HTTP header (.eu domain), the language switcher takes me to the .pl domain with HTTP header instead of HTTPS.

When I am on a website with HTTPS header (.pl domain), clicking on the “En” flag takes me to the .eu domain with HTTPS header when it should set HTTP header.

In the Plugin settings, I have two domains set for each language version with the appropriate headers entered, but it does not help.

How can I fix this issue?

I noticed some “incompatibilities” with WordPress expecially with the password-protected post. When a user insert the password the page go blank to the following URL:
https://somedomain.xy/wp-login.php?action=postpass

When I remove the HTTP Headers rules all goes alright.

The question is.. are HTTP Headers not compatible with WordPress or is there a solution for that issue?

Thank You guys
G.

header( ‘Location: ‘. get_the_permalink( pll_get_post( 1234 ) ) );

First, function_exists( ‘pll_get_post’ ) called in the part of the form submit script returns true, so we have the function available. Then, I checked on the error and discovered that it occurred because pll_get_post() returned null here. According to the doc, this happens if the language it uses to retrieve the specified post could not be found. The doc linked above actually says that the second parameter of pll_get_post() is:

“Language code, defaults to current language”

which means that pll for some reason fails to retrieve the correct locale of the executing page X, if it’s being called in a PHP Form submit script, called via that page X. When I do this in an AJAX script, which in theory is also only indirectly tied to a language-specific page X, which fires the request (just as for the form submit); interestingly everything works. My workaround attempt for this was:

header( ‘Location: ‘. get_the_permalink( pll_get_post( 1234, substr( get_locale(), 0, 2 ) ) ) );

And, by retrieving the locale language code explicitly in this way, the script and redirect worked perfectly. So I suppose that’s a bug which is not supposed to happen? Or does anyone know why this happens, and I’m missing sth out?

Thanks in advance, Peter