View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001857 | OXID eShop (all versions) | 4.08. Cache | public | 2010-05-27 14:08 | 2012-12-10 13:38 |
| Reporter | manuel | Assigned To | |||
| Priority | immediate | Severity | block | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Summary | 0001857: GET-Parameter leads to cached NOINDEX-Header for startpage | ||||
| Description | We have an OXID EE 4 under heavy load with jumping google ranks. We thought that the origin of this was a relaunch for shop earlier and old links but tuesday the shop vanished from the google index completely. A major crash for every page! Our Analysis: Enable Dynamic Content Caching in the Backend. Call the uncached start page with an "unknown" GET Parameter like a GET-Parameter of a Google Adwords campaign and oxUbase::_processRequest puts a "NOINDEX, FOLLOW" in the header. // non admin, request is not empty and was not processed by seo engine
if ( $myUtils->seoIsActive() && !isSearchEngineUrl() && ( $sStdUrl = getRequestUrl( '', true ) ) ) {
// fetching standard url and looking for it in seo table
if ( $this->_canRedirect() && ( $sRedirectUrl = oxSeoEncoder::getInstance()->fetchSeoUrl( $sStdUrl ) ) ) {
$myUtils->redirect( $this->getConfig()->getShopURL() . $sRedirectUrl, false );
} else {
// forcing to set noindex/follow meta
$this->_forceNoIndex();
And this "NOINDEX" Header will be cached by the OXID Dynamic Content Caching for your normal SEO startpage URL. If Google fetches this cached state, say goodbye to your actual SERP Position temporarily. Try: - Enable Content Caching on http://demoshop.oxid-esales.com/enterprise-edition/ (start is cached per default) - Call http://demoshop.oxid-esales.com/enterprise-edition/?foo=bar with a fresh cach - Call http://demoshop.oxid-esales.com/enterprise-edition/ And you got the "NOINDEX". That means imho that the cached template for the startpage with the unknown GET-Parameter AND the correct call of the correct call is the same, because oxUbase::getViewId can not know every GET-Parameter for returning the ID used for a cached Template. And that there is no easy way writing a module without changing the whole caching mechanism for "repairing" that. We would need a module like Zend_Cache checking every GET-Parameter. Our workaround: Making an http request in oxCache::reset for the starpage automatically so that we minimize the time to a minimum in which a customer with a "bad" request could create a "bad" cache state destroying search engine ranks temporarily. Regards | ||||
| Tags | No tags attached. | ||||
| Theme | |||||
| Browser | |||||
| PHP Version | |||||
| Database Version | |||||
|
|
Relations: 0001373 - Displaying the head-Tag 0000692 - (Comment 2009-03-16 15:54 from arvydas_vapsva) "Seems like this approach does not work, so we could solve it by adding special "noindex, follow" meta tags instead of emitting 404 header." |
|
|
Solution for the problem is deep in code ("views/oxubase.php"). As we can't release custom module to fix the problem, you will have to wait until next release or modify file by yourself. Manual instructions: open "views/oxubase.php" and search for method "getViewId()", find LAST: return $this->_sViewId; and modify it: return $this->_sViewId."|".( (int) $this->_blForceNoIndex ); The problem should be gone! |
