{"id":28430,"date":"2026-09-08T21:56:08","date_gmt":"2026-09-08T18:56:08","guid":{"rendered":"https:\/\/alienroad.com\/yandex-bilgi-bankasi\/managing-access-rights\/"},"modified":"2026-09-09T00:47:43","modified_gmt":"2026-09-08T21:47:43","slug":"managing-access-rights","status":"publish","type":"ar_ykb","link":"https:\/\/alienroad.com\/yandex-bilgi-bankasi\/managing-access-rights\/","title":{"rendered":"Managing access rights"},"content":{"rendered":"<p>Once a site is verified, access can be handed to other people through named roles instead of shared passwords. Only a user who holds the <strong>Owner<\/strong> role \u2014 earned by verifying ownership, not by being granted it \u2014 can assign, edit or revoke anyone else&#8217;s access.<\/p>\n<h2>The four roles<\/h2>\n<ul>\n<li><strong>Owner<\/strong> \u2014 full control, including managing other users. A site can have several owners; each one verified independently.<\/li>\n<li><strong>Edit<\/strong> \u2014 full view and edit of site data, but cannot grant or revoke roles. Users who held delegated rights under the older system were migrated into this role automatically.<\/li>\n<li><strong>View<\/strong> \u2014 read everything, change nothing.<\/li>\n<li><strong>Partial access<\/strong> \u2014 a defined slice: the Indexing tools (crawl statistics, searchable pages, site structure, page check, reindexing, sitemap files, crawl rate, titles and descriptions, JavaScript rendering), the Efficiency tools (query monitoring and statistics, page statistics, product range analytics), search appearance settings (snippets, sitelinks, site region), feeds, or reviews.<\/li>\n<\/ul>\n<p>Each user holds exactly one role; they do not stack.<\/p>\n<h2>How assignment actually completes<\/h2>\n<p>Granting a role does not put the site in the recipient&#8217;s account. They must sign in with the Yandex ID that was named, add the site themselves \u2014 <em>the identical address<\/em>, including protocol and <code>www<\/code> \u2014 and the rights then confirm automatically. Almost every &#8220;I was given access but it says unverified&#8221; case is one of those three conditions: wrong Yandex ID, site not added, or a different address variant.<\/p>\n<h2>Revoking access properly<\/h2>\n<p>Clicking <strong>Revoke role<\/strong> in the console is only half the job for a user who verified ownership themselves. Their verification marker also has to be removed from the site \u2014 the meta tag with their code, their <code>yandex_&lt;code&gt;.html<\/code> file, or their TXT record \u2014 otherwise the next automated check simply re-establishes them as an owner. Revoking a role you assigned, on the other hand, takes effect immediately.<\/p>\n<h2>Moving a site between accounts<\/h2>\n<p>Data can be transferred to a different Yandex ID either by adding and verifying the site under the new ID, or by having the new ID added and assigned a role. The site history copies across in full; nothing is recalculated and nothing is lost.<\/p>\n<h2>The handover failure<\/h2>\n<p>The expensive scenario is predictable: the only verified owner leaves the company, verification was a meta tag, the site has since been rebuilt, and the marker is gone. Nobody can now assign roles, and re-establishing ownership means editing DNS or the site root \u2014 which is exactly what nobody has access to. Recording who holds ownership, and by which method, costs one line in a handover document.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Once a site is verified, access can be handed to other people through named roles instead of shared passwords. Only a user who holds the Owner role \u2014 earned by verifying ownership, not by being granted it \u2014 can assign, edit or revoke anyone else&#8217;s access. The four roles Owner \u2014 full control, including managing [&hellip;]<\/p>\n","protected":false},"menu_order":6,"template":"","meta":{"footnotes":""},"ar_ykb_kategori":[752],"ar_ykb_etiket":[],"class_list":["post-28430","ar_ykb","type-ar_ykb","status-publish","has-post-thumbnail","hentry","ar_ykb_kategori-access-rights"],"_links":{"self":[{"href":"https:\/\/alienroad.com\/wp-json\/wp\/v2\/ar_ykb\/28430","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/alienroad.com\/wp-json\/wp\/v2\/ar_ykb"}],"about":[{"href":"https:\/\/alienroad.com\/wp-json\/wp\/v2\/types\/ar_ykb"}],"version-history":[{"count":2,"href":"https:\/\/alienroad.com\/wp-json\/wp\/v2\/ar_ykb\/28430\/revisions"}],"predecessor-version":[{"id":29021,"href":"https:\/\/alienroad.com\/wp-json\/wp\/v2\/ar_ykb\/28430\/revisions\/29021"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/alienroad.com\/wp-json\/wp\/v2\/media\/28812"}],"wp:attachment":[{"href":"https:\/\/alienroad.com\/wp-json\/wp\/v2\/media?parent=28430"}],"wp:term":[{"taxonomy":"ar_ykb_kategori","embeddable":true,"href":"https:\/\/alienroad.com\/wp-json\/wp\/v2\/ar_ykb_kategori?post=28430"},{"taxonomy":"ar_ykb_etiket","embeddable":true,"href":"https:\/\/alienroad.com\/wp-json\/wp\/v2\/ar_ykb_etiket?post=28430"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}