Murkuz SEO

Get a side-by-side performance summary for all of the user's sites. source defaults to 'combined' (Google + Bing merged via the portfolio dashboard's honest merge). Use source='google' or source='bing' for a single engine. Google and Bing clicks and impressions cover the SAME 28-day window, given as window.start..window.end (the latest day both engines have reported), and every change compares it with the 28 days before it (window.previous_start..window.previous_end); a site gets a change only when its stored daily history covers both windows. Bing average position is full Bing history (Bing reports no daily position), so combined average position is null on purpose. average_position.change_percent is the percent change of the position number, so a NEGATIVE value means the site ranks better (better_when='lower'). Per-site rows always carry a Bing sub-signal so a Bing-winning site is never hidden. 'all' is a back-compat alias for 'combined'. Every site the caller owns is included and nothing is cut, so there is no offset to pass: the pagination block reports truncated false and the count, which is how you can tell this from a first page.

Bing's own related keywords for a set of seed terms, with volume, competition and cost-per-click. Bing surfaces different long-tail phrasing from Google, so this is worth running alongside Keyword_Ideas rather than instead of it. Costs 9 credits per call regardless of how many seeds you pass, so batch them into one call. CAP: this returns at most the number of rows you asked for, and there is no offset or paging here because every call is billed and a second page would be a second charge. A response holding exactly that many rows is capped, not complete: more probably exist. To see more, raise the row count in a SINGLE call, up to its maximum, rather than calling again.

Bing search volume, competition and cost-per-click for up to 200 keywords, with monthly history. Use when a site draws meaningful Bing traffic, which Bing_Search_Performance will tell you, or when the audience skews to Windows and Edge defaults, where Bing's share runs well above its headline number. Costs 9 credits per call REGARDLESS of how many keywords you pass, so always send them in one batch: 200 keywords costs exactly what 1 does. CAP: one row comes back per keyword accepted and the list is cut at 200, so a longer list loses its tail before the lookup runs. Compare the rows returned against the keywords you sent. There is no paging here: each call is billed.

The keywords Bing associates with one specific page, each with a relevance score from 0 to 1. Point it at your own article to see what Bing thinks it is about. A mismatch against your focus keyword is a concrete signal the page is being read as something other than what you intended. Costs 9 credits per call. CAP: this returns at most the number of rows you asked for, and there is no offset or paging here because every call is billed and a second page would be a second charge. A response holding exactly that many rows is capped, not complete: more probably exist. To see more, raise the row count in a SINGLE call, up to its maximum, rather than calling again.

Read clicks, impressions, CTR, average position, top queries and top pages from the caller's own connected Bing Webmaster property. This is first-party data read with the site's own Bing credentials and it consumes zero credits. Use this, not the Bing_Keyword_* research tools, whenever the question is about how a site the caller owns is actually performing on Bing. The Bing_Keyword_* tools answer a different question: they return third-party keyword estimates for any domain and they do cost credits. Note that Bing supplies position and CTR only as a fixed rolling snapshot, so those two figures are never window-matched even when clicks and impressions are. limit and offset apply to both returned lists, and the pagination block carries an entry for each. PAGING: this returns one page of rows. The pagination block reports returned, total_available, truncated and next_offset for every list in the response. Check truncated before drawing a conclusion: when it is true these rows are a slice, not the whole picture, and a total or a 'none of them' claim built on them is wrong. Read the rest with offset set to next_offset, or raise limit.

The keywords Bing associates with a whole domain, with Bing volume, competition and cost-per-click. Point it at a competitor to see their Bing footprint. For your OWN site's measured Bing performance, use Keyword_Rankings with source='bing' instead: that is real data from the connected account and costs nothing. Costs 9 credits per call. CAP: this returns at most the number of rows you asked for, and there is no offset or paging here because every call is billed and a second page would be a second charge. A response holding exactly that many rows is capped, not complete: more probably exist. To see more, raise the row count in a SINGLE call, up to its maximum, rather than calling again.

Show the changes logged for the caller's sites (by Track_Change, by the Murkuz editor, or by marking an Action Item done) and whether each worked: direction (up, down, flat, or early when the page has too little traffic to say), clicks per day before and after, change in percent and average position of the target searches, at the 7, 14 and 28 day checks. Use it for 'did that change work?', 'what did my last edits do?' and 'which changes lost traffic?'. Free accounts see which changes are tracked and which have a result ready, with no numbers; the numbers are on Pro. Newest first. A result with direction early means the traffic was too small to judge, not that the change failed. PAGING: this returns one page of rows. The pagination block reports returned, total_available, truncated and next_offset for every list in the response. Check truncated before drawing a conclusion: when it is true these rows are a slice, not the whole picture, and a total or a 'none of them' claim built on them is wrong. Read the rest with offset set to next_offset, or raise limit.

Find what a competitor ranks for that you don't. Returns every keyword where they appear and you do not appear at all, with search volume, difficulty, their position and their estimated traffic. This is structurally impossible with Search Console, which only ever sees your own property. Pass site_id and your domain is resolved automatically; otherwise pass your_domain. You supply the competitor: pick one you already know you compete with, or take a repeat domain from SERP_Snapshot on a keyword that matters. Costs 3 credits for the default 100 rows. CAP: this returns at most the number of rows you asked for, and there is no offset or paging here because every call is billed and a second page would be a second charge. A response holding exactly that many rows is capped, not complete: more probably exist. To see more, raise the row count in a SINGLE call, up to its maximum, rather than calling again.

Get the last sync timestamp for each connected data source: Search Console (gsc), Analytics 4 (ga4) and Bing Webmaster (bing). A source that is not connected, or that has never synced, returns null rather than a zero, so null means 'no data yet', never 'no traffic'.

What Google currently knows about one URL: index status, last crawl, the canonical Google actually chose versus the one you declared, robots and mobile usability. Cached for one hour per site and URL, because this API's quota is far tighter than Search Analytics' own; a repeated call within the hour returns the cached result rather than spending quota again.

Turn one topic into a content plan. Returns related keywords around a seed term, each with its own search volume, difficulty, competition and intent, ordered by volume. Use it to decide what is worth covering, then check Keyword_Rankings to see which of those the site already ranks for. Costs 2 credits for the default 50 ideas. CAP: this returns at most the number of rows you asked for, and there is no offset or paging here because every call is billed and a second page would be a second charge. A response holding exactly that many rows is capped, not complete: more probably exist. To see more, raise the row count in a SINGLE call, up to its maximum, rather than calling again.

Find out whether a keyword is worth writing about. Returns monthly search volume, ranking difficulty (0-100), cost-per-click, what the searcher actually wants (informational / commercial / navigational / transactional) and 12 months of month-by-month volume history. Up to 100 keywords in one call: always batch them rather than calling once per keyword, as the cost is mostly per call. Use this for keywords the site does NOT already rank for; for keywords it does, Keyword_Rankings has measured data and is free. Costs 2 credits for a typical 50-keyword lookup. CAP: one row comes back per keyword accepted and the list is cut at 100, so a longer list loses its tail before the lookup runs. Compare the rows returned against the keywords you sent rather than assuming one row per keyword sent. There is no paging here: each call is billed, so send a longer list as further deliberate calls.

Get top keyword rankings for a site. source defaults to 'combined'. For 'combined' the response returns a per-source query list, each row tagged with its source and window: Google rows use date_range, Bing rows use a rolling window with no per-day breakdown. Per-query clicks are NOT summed across engines because their windows differ (that would overstate). Use source='google' or source='bing' for a single engine. 'all' is a back-compat alias for 'combined'. In combined the pagination block carries one entry per engine (google.rows and bing.rows), because the two lists truncate independently. total_available counts the rows in Murkuz's synced snapshot, which each sync caps at its own top 500 by clicks, so a total sitting at that cap is a floor rather than the site's full query count. PAGING: this returns one page of rows. The pagination block reports returned, total_available, truncated and next_offset for every list in the response. Check truncated before drawing a conclusion: when it is true these rows are a slice, not the whole picture, and a total or a 'none of them' claim built on them is wrong. Read the rest with offset set to next_offset, or raise limit.

One call, everything Murkuz knows about a single page: its Search Console performance (top queries, clicks, impressions, position), its GA4 behaviour, whether any of the site's other pages compete with it for the same queries, and any active insights already raised for it. Use this before deciding whether a page needs a content fix, a consolidation, or is simply fine. limit and offset page the query list only; competing_pages and active_insights are returned in full and the pagination block says so. PAGING: this returns one page of rows. The pagination block reports returned, total_available, truncated and next_offset for every list in the response. Check truncated before drawing a conclusion: when it is true these rows are a slice, not the whole picture, and a total or a 'none of them' claim built on them is wrong. Read the rest with offset set to next_offset, or raise limit.

Every sitemap submitted for this property, with its pending state, warnings, errors and indexed URL count. Google returns the whole list, so this is never a page: the pagination block reports truncated false and the count, which is how you can tell a complete list from a first page.

Queries where two or more of your own pages compete for the same searcher, splitting the ranking signal Google would otherwise give one page. Goes to Google on every call. POSITION: average position is impression-weighted across queries, devices and countries, not a rank-tracker rank. Deep positions rest on sparse data because they are only recorded when a searcher actually scrolls that far. Treat absolute positions as directional and prefer position deltas between periods when judging change. PAGING: this returns one page of rows. The pagination block reports returned, total_available, truncated and next_offset for every list in the response. Check truncated before drawing a conclusion: when it is true these rows are a slice, not the whole picture, and a total or a 'none of them' claim built on them is wrong. Read the rest with offset set to next_offset, or raise limit.

Pages on a steady three-window slide, not just one bad period: clicks must fall in both consecutive steps. Fetches three separate 30 day windows live per call, so this is the slowest tool in this module; run it sparingly. PAGING: this returns one page of rows. The pagination block reports returned, total_available, truncated and next_offset for every list in the response. Check truncated before drawing a conclusion: when it is true these rows are a slice, not the whole picture, and a total or a 'none of them' claim built on them is wrong. Read the rest with offset set to next_offset, or raise limit.

Pages earning less than half the click-through rate a page at their depth usually gets, computed live with your own impression threshold. Goes to Google on every call; prefer Keyword_Rankings for a quick check on a preset window. POSITION: average position is impression-weighted across queries, devices and countries, not a rank-tracker rank. Deep positions rest on sparse data because they are only recorded when a searcher actually scrolls that far. Treat absolute positions as directional and prefer position deltas between periods when judging change. PAGING: this returns one page of rows. The pagination block reports returned, total_available, truncated and next_offset for every list in the response. Check truncated before drawing a conclusion: when it is true these rows are a slice, not the whole picture, and a total or a 'none of them' claim built on them is wrong. Read the rest with offset set to next_offset, or raise limit.

Queries sitting just off page one with enough impressions that closing the gap to position 3 would move the needle, computed live with your own thresholds. This is the live, tunable counterpart to the striking-distance findings SEO_Insights already surfaces from the synced cache. Slower than SEO_Insights because it goes to Google on every call, and unlike SEO_Insights the thresholds are yours to set. POSITION: average position is impression-weighted across queries, devices and countries, not a rank-tracker rank. Deep positions rest on sparse data because they are only recorded when a searcher actually scrolls that far. Treat absolute positions as directional and prefer position deltas between periods when judging change. PAGING: this returns one page of rows. The pagination block reports returned, total_available, truncated and next_offset for every list in the response. Check truncated before drawing a conclusion: when it is true these rows are a slice, not the whole picture, and a total or a 'none of them' claim built on them is wrong. Read the rest with offset set to next_offset, or raise limit.

Pages that lost clicks between this window and the one immediately before it, with a best-effort diagnosis of why: ranking loss, CTR collapse, falling demand, or mixed. Fetches two live windows per call, so it is slower than the tools that read the synced cache. POSITION: average position is impression-weighted across queries, devices and countries, not a rank-tracker rank. Deep positions rest on sparse data because they are only recorded when a searcher actually scrolls that far. Treat absolute positions as directional and prefer position deltas between periods when judging change. PAGING: this returns one page of rows. The pagination block reports returned, total_available, truncated and next_offset for every list in the response. Check truncated before drawing a conclusion: when it is true these rows are a slice, not the whole picture, and a total or a 'none of them' claim built on them is wrong. Read the rest with offset set to next_offset, or raise limit.

Check how much research allowance is left before running anything expensive. Returns credits remaining, how much of this month's research allowance has been used, when it refreshes, and what each research action costs. Free: this never consumes credits. Call this first before a large sweep across many keywords, competitors or pages, so you can budget the run rather than hitting the limit part-way through. Also returns the research wallet: prepaid dollars used once credits run out, billed at the data cost plus a 10% fee, with a receipt on every research result.

List every site on the account, each with its name, domain, public URL, default language and a connections block saying which data sources are wired up: Search Console, Analytics 4 and Bing Webmaster, each with connected true or false and when it last synced. Start here to find the site_id every other tool needs, and to check a source is connected before asking for its data. Every site is returned and nothing is cut, so there is no limit or offset to pass: the pagination block reports truncated false and the count, which is how you can tell a complete list from a first page.

Rank pages by where effort actually pays off, by crossing search ranking potential against GA4 conversion rate. When at least one candidate page has a measured GA4 conversion, every page lands in one of four groups: rank_up_now (close to page one already and converts well, push it), improve_page_first (real ranking potential but converts poorly, fix the page before chasing more traffic to it), protect (already converts well but limited further ranking room, do not break what works), deprioritise (neither), returned under quadrants with quadrants_assigned: true. The split point on each axis is that axis's own median across the pages being compared, and both medians are returned so the split is auditable rather than a hidden cutoff. When NO candidate page has a measured GA4 conversion in this window, which is the normal case for a site without conversion tracking enabled, the conversion axis carries no signal: a median of zero would put every page 'at or above median' and mislabel all of them, protect included, so quadrants are not assigned. The response instead carries quadrants_assigned: false and a ranked_by_potential_only list, pages ranked by search ranking potential alone, with a note explaining why. Only pages with both a Search Console ranking signal and a measured GA4 session count are placed; a page missing one side cannot be scored honestly and is left out rather than scored with a zero. Both limit and offset apply per quadrant, and the pagination block carries one entry per quadrant, so a quadrant holding 80 pages is never mistaken for one holding 20. PAGING: this returns one page of rows. The pagination block reports returned, total_available, truncated and next_offset for every list in the response. Check truncated before drawing a conclusion: when it is true these rows are a slice, not the whole picture, and a total or a 'none of them' claim built on them is wrong. Read the rest with offset set to next_offset, or raise limit.

See what a page ranks for and what visitors do once they land, in one call. Returns the page's top Search Console queries (clicks, impressions, CTR, position) beside its GA4 behaviour (sessions, engagement rate, bounce rate, average session duration, conversions) for the same window. Search Console and GA4 use different URL shapes for the same page (a full URL versus a bare path), so the two sides are matched on path, not on the raw strings each system returns. When GA4 is not connected for this site, the behaviour side comes back as a clear 'not connected' result rather than zeros. total_clicks and total_impressions are summed over every query for the page, not over the returned page of rows, so they stay correct while top_queries is a slice. PAGING: this returns one page of rows. The pagination block reports returned, total_available, truncated and next_offset for every list in the response. Check truncated before drawing a conclusion: when it is true these rows are a slice, not the whole picture, and a total or a 'none of them' claim built on them is wrong. Read the rest with offset set to next_offset, or raise limit.

Run the Search Console vs GA4 traffic health check across every site the caller owns that has both integrations connected. A site missing either integration still appears in the results, with connected: false and a reason naming which one is missing, rather than being dropped silently from the comparison. Check the pagination block before saying anything about the portfolio as a whole: a caller with 90 sites gets 50 by default, and 'every site is healthy' read off those 50 is a claim about the page, not the portfolio. PAGING: this returns one page of rows. The pagination block reports returned, total_available, truncated and next_offset for every list in the response. Check truncated before drawing a conclusion: when it is true these rows are a slice, not the whole picture, and a total or a 'none of them' claim built on them is wrong. Read the rest with offset set to next_offset, or raise limit.

The raw cut of Search Console data: any dimensions, any filters, any sort, fetched live for this call only. This is slower than Keyword_Rankings, which reads Murkuz's own synced cache, so prefer that when a preset window is enough and reach for this only when the question needs a window, filter or dimension combination it does not expose. POSITION: average position is impression-weighted across queries, devices and countries, not a rank-tracker rank. Deep positions rest on sparse data because they are only recorded when a searcher actually scrolls that far. Treat absolute positions as directional and prefer position deltas between periods when judging change. PAGING: this returns one page of rows. The pagination block reports returned, total_available, truncated and next_offset. total_available is null here because the API does not report how many rows exist, so it is left null rather than guessed; truncated is then true when the fetch came back exactly full, which means more rows are probably waiting. Check truncated before drawing a conclusion, and read the rest with offset set to next_offset.

Which search queries are associated with revenue, for sites with GA4 e-commerce tracking enabled. Revenue per page is measured directly from GA4, not estimated. GA4 does not record which search query drove which purchase, so that page revenue is then split across the page's Search Console queries by click share, the one estimated step in the chain. Every response carries attribution_method: 'click_share_estimate' and a plain-language note. Present the page-level revenue as real and the per-query split as a proportional estimate, never as measured. total_revenue covers every revenue-earning page GA4 reported for the window, not just the pages on this page of rows. PAGING: this returns one page of rows. The pagination block reports returned, total_available, truncated and next_offset for every list in the response. Check truncated before drawing a conclusion: when it is true these rows are a slice, not the whole picture, and a total or a 'none of them' claim built on them is wrong. Read the rest with offset set to next_offset, or raise limit.

Read the findings Murkuz has already stored for a site from its synced Search Console data. This is a read: it reports what was found, it does not change anything on the site. Every insight carries: potential_clicks and realistic_ceiling_clicks (the hard cap, clicks never exceed impressions * realistic_max_ctr), impression_base (the exact impressions used), window_days (28, so potential is per that window not per calendar month), confidence_label (high/medium/low), metric_current vs metric_target, evidence, and source (google/bing/combined). Use confidence_label and potential_clicks to decide which findings are worth the customer's time; the fix itself is made wherever the page actually lives. Optionally filter by insight type (striking_distance, low_ctr, cannibalization, etc.), status, action_type, or source. Returns an object with an insights list, not a bare list: pagination.insights carries returned, total_available, truncated and next_offset, where total_available is how many insights match the filters in full. PAGING: this returns one page of rows. The pagination block reports returned, total_available, truncated and next_offset for every list in the response. Check truncated before drawing a conclusion: when it is true these rows are a slice, not the whole picture, and a total or a 'none of them' claim built on them is wrong. Read the rest with offset set to next_offset, or raise limit.

See who you're actually up against for a keyword. Returns the results on page one right now: their titles, descriptions, URLs and domains, plus which SERP features are present (featured snippet, people also ask, AI overview, video pack). Search Console can tell you that you sit at position 14; it can never tell you who holds position 1 or what their headline says. Use this before writing against a keyword, before rewriting a meta title for a Low-CTR insight, and to judge whether an AI overview is eating the clicks. Search operators such as 'site:' are not supported. Costs 1 credit. CAP: this returns at most the number of rows you asked for, and there is no offset or paging here because every call is billed and a second page would be a second charge. A response holding exactly that many rows is capped, not complete: more probably exist. To see more, raise the row count in a SINGLE call, up to its maximum, rather than calling again.

Get Google Analytics 4 (GA4) traffic, engagement and conversion data for a site: total and organic sessions, users, new users and page views, engagement rate, bounce rate, average session duration, conversions and conversion rate, top landing pages, traffic sources, conversion events, and a daily trend. This is DISTINCT from the Search Console tools, which return search performance (clicks, impressions, position). Use Search_Analytics or Keyword_Rankings to see how a site performs in search, and Site_Analytics to see what visitors do once they arrive. Every figure is the real value synced from the site's GA4 property; nothing is estimated. GA4 currently syncs the last_28_days window; other date_range values return the latest snapshot with a note. The response carries connected/synced flags and a note when GA4 is not set up, and a units block because property-level engagement_rate and bounce_rate are 0-1 fractions while the per-row values are 0-100 percentages. Revenue is included only when the property has e-commerce tracking enabled. limit and offset apply to top_landing_pages and traffic_sources, which get one pagination entry each; conversion_events and daily_metrics are returned in full. PAGING: this returns one page of rows. The pagination block reports returned, total_available, truncated and next_offset for every list in the response. Check truncated before drawing a conclusion: when it is true these rows are a slice, not the whole picture, and a total or a 'none of them' claim built on them is wrong. Read the rest with offset set to next_offset, or raise limit.

Get one site's name, domain, public URL, default language, when it was added, and which data sources are connected to it with each one's last sync time. Same shape as a row from My_Sites.

Ask Google to recrawl a sitemap you already publish, because it is new or has changed. It submits the URL of an existing file and nothing more: it does not generate, host or edit the sitemap, so publish the updated file yourself first. Writes to Google; this is the connector's only write.

Log a change the caller made to a page, so Murkuz measures what it did to the page's Search Console clicks, impressions and position 7, 14 and 28 days later, against the same number of days before. Call it when the caller says they just changed, rewrote, added or fixed something on a page. Pass what_changed as a short plain sentence (for example 'Rewrote the title to lead with the price'). Pass keywords for the searches the change was aimed at, if they said which. Returns the record id and the dates the 14 and 28 day results land. Free; works on every plan. Needs Search Console connected on the site to be measured; without it the change is logged but never measured. Read the results with Change_Impact.

Sanity-check that Search Console and GA4 agree on how much organic traffic a site gets. Compares Search Console clicks against GA4 organic sessions for the same window and returns the ratio plus a diagnosis: under 0.5 means tracking_gap (GA4 is missing traffic Search Console can see, often a missing or misfiring tag), over 1.5 means over_counting (GA4 is crediting organic sessions Search Console never sent, often a tagging or medium-classification issue), otherwise healthy. A 10 to 20 percent mismatch either way is normal: the two systems count different events and attribute differently around redirects and consent banners, so only flag the extremes.